# Study on Effective Temporal Data Retrieval Leveraging Complex Indexed Architecture
## 2 Temporal Database Architecture
### Temporal Database Architecture--Granularity Levels
In comparison with the default values replacing the undefinition, respectively in an unlimited time manner, there is no problem with the consecutive interpretation of the values. Moreover, such a concept can be used generally for any data type, which just limits the problem of designing a suitable value to replace an undefined value, both physically in the database and interpretation and indexing. Besides, it should be emphasized that using a different value to specify an undefined value requires additional disc requirements because these values must be physically stored in the database. The simplification of the second model in Figure 4 is a representation of a third object-oriented time model. Its representation is also shown in Figure 4 (last model). The time representation is expressedonly by the beginning of the validity, and therefore each additional state automatically limits the validity of the direct predecessor. The primary key is again composite but consists of only two elements--the object identifier (ID) and the beginning of validity (BD). The advantage of the mentioned third model is the reduction of disk space requirements. On the other hand, in such a system, it is not possible to directly model and identify undefined states, these must therefore be defined explicitly [16; 21]. Principles of undefined state management and identification are covered in [24; 25] It must be stated either explicitly [16] or by pointing the state to the undefined memory locator [25] improving performance, whereas the whole state is grouped, whereas the object level granularity is used. Figure 4 shows only management in terms of the validity forming uni-temporal architecture. In general, multi-temporal systems can be used to model multiple time dimensions by allowing data corrections. The attribute-oriented temporal approach is based on the mainstream system used within the temporal paradigm--object granularity, in which any change causes the creation of a new state, which may lead to the need to store duplicate values if some attributes do not change their values over time with each Update operation. This causes increased costs for disk space, processing, storage, and evaluation. In such a system, there are no direct links between the Update command and the attribute change. It requires the sequential comparison of individual values forming states, or versions of objects [26]. The aspect of value change also plays an important role here, with an emphasis on identifying a significant change. The minimum change in value may not be important for the system and may not need to be recorded in more detail [10; 16; 27]. In this case, it can be declared that the existing value expresses another state without change. The significant increase in the amount of data to be processed and its heterogeneity brought the need to create a new temporal architecture that could cover current trends, object volatility, sensory networks, and overall monitoring of object states throughout the time spectrum. The essence of the implemented solution is to move the granularity of processing to the level of the attribute. Thanks to this, individual changes are always associated with a specific attribute, the overall view of the object in a defined time is created by the composition of individual partial values of attributes. Principles are defined in [28]. Technology improvements of the temporal layer are defined [28] by correlating the same data type to the common group. The architecture consists of three layers. The first layer is conventional covering _Current valid state_ images. _Historical data and future valid images_ are in the third layer. Finally, the core element is supervised by the second layer (_Temporal management_). Any change is monitored and maintained by the temporal module. Each change of the attribute fires adding one extra row into the temporal table (located in the _Temporal management_ layer). Architecture is in Figure 5. The left part of the figure shows the architecture and interconnection to the application.