# Study on Effective Temporal Data Retrieval Leveraging Complex Indexed Architecture
## 2 Temporal Database Architecture
### Temporal Database Architecture--Granularity Levels
Blue arrows represent the data communication between individual layers. Whereas the whole communication is supervised by the _Temporal management_, future valid states cannot be routed to the current layer directly. Similarly, current states cannot be  
Figure 4: Object-level temporal architecture. operated and marked as historical without the approval and acknowledgment of the temporal management layer. External applications can be mapped either into the temporal management (green arrow in the left part of the figure) or to the current valid states, as well (red arrows in the left parf of the figure). The reason to propose both techniques is based on the existing applications dealing with only current valid states. The aim is to offer the possibility to remain the original application without any change, only the flag to the temporal layer as the supervisor is done. Note, that the data provided is secured, thus the application cannot directly locate individual layers. The right part of Figure 5 shows the data flow. If the new state is created, the system creates the Update statement of the existing state (1) by transforming existing state into the historical (by the assumption, that new state should be immediately valid). It is done by two phases--_actual \(\rightarrow\) historical_ (2) interconnecting current valid states and temporal management. The new state is inserted to the temporal layer. The original state is marked as historical and loaded into the third layer (3). Afterwards, the newly loaded state is denoted as current by the _new \(\rightarrow\) actual_ operation (4). Finally, the user or application gets the acknowledgement of the executed and approved operation (5). By improving the structure, the way of manipulation, as well as the access methods, we found additional properties for optimization and thus increased performance. The next step was to create an extended approach for working with the extended attribute level temporal approach. The system is also based on the granularity of attributes (columns). The main difference is the modification of the temporal change table in the second layer--an explicit definition of the type of the executed command was added--the Insert, Delete, Update, or volatility methods. It is also necessary to think about the management of undefined states, their explicit definition, and transformation. In the case of the Update temporal statement, a numeric value for the data type category is also stored. Again, a three-level architecture is used, but only the first level remains unchanged, with the task of connecting to existing applications and accessing currently valid records. Historical data, resp. images of planned states are, in contrast to the previous solution, grouped based on the category of data types, the so-called basic types. Each category is assigned a table for storing attribute values. The primary key of this table is the numeric identifier (ID) obtained from the sequence and assigned by the trigger. The next attribute contains the value of the data type of the relevant category it represents. The overall system is managed using the proposed semantics--algorithms of triggers, procedures, and functions. Although additional attributes are added to the changing table, increasing the disk space requirement, the execution of the Select statement is significantly streamlined, simplifying the identification of the change made and the state construction process. The required number of tables for historical data is also significantly reduced. If the original columnar approach given as we stated were used, another (separate) table would be defined for each temporal attribute, in which case, 4-5 tables will often suffice, depending on the characteristics and structure of the stored temporal value. We use the term base core data type. It combines specific data types implemented in the data model into common categories. For example, numeric representations of Integer, Number, Float can be categorized together as type Number.