Temporal Database Concepts

This chapter will provide you with complex information related to temporal modeling and physical data model representations. You will be introduced to the historical evolution of databases originating from conventional (non-temporal) models by using additional extensions, following which the processing level – object, attribute, and group granularity – will be discussed. The object level is signified by the primary key extension, while attribute granularity associates the temporal sphere for each attribute separately. Therefore, a universal solution is built on group granularity, where temporal groups can be composed dynamically based on real workloads. Thanks to that, the system can automatically apply new rules and build on and structure existing groups. However, always keep in mind that the principle of the temporal table is based on the opportunity to hold multiple states for each object, delimited by the validity time frame.

We will...

The origin and evolution of temporal models

The need to preserve individual states and limit them over time arose with the advent of the first database systems in the 1960s. Several ideas were brought forward for managing and modeling these types of data, with an emphasis on validity, but most of them were only treated theoretically. The main limitation was the technical support costs in terms of the hardware components, limiting the possibility of the further expansion of technical equipment.

A more significant shift occurred during the boom of relational database systems. They are based on entities and relationships, creating a data model separate from the physical hardware. The main features are integrity, individual rows being identified by primary keys, as well as the precise structure supervised by transaction support. Moreover, individual structures can be optimized using the process of data normalization to maintain efficiency and data quality. The data access itself is...

The object-oriented temporal approach

It is clear that despite several improvements to historical databases, referenced database concepts are unsustainable for practical use in the long run. In order to make the right decision and reflect data changes, it is not enough to store and evaluate only current valid data; historical data also needs to be defined and operated. Over the decades, several attempts have been made to create a temporal model. The object-oriented temporal approach was the basis of this. Moving conventional processing to an object-level temporal model is based on the primary key, which uniquely identifies any object in a conventional database. A conventional system uses just one object version expressing the current valid state, while a temporal model stores the whole evolution. Thus, to manage the object, several versions must be identified and processed. To do so, the original primary key is extended to reference the version. It is mostly modeled by the validity...

The temporal aspect of management

In the previous section, we referred to uni-temporal systems. The time spectrum was expressed using either a time interval (BD, ED) or a single time point (BD). This allows you to store individual states and their positional arrangement over time. Uni-temporal systems are usually characterized by the validity of the record, where overlaps are not allowed. The temporal paradigm rule requires the creation of a consistent state in which each attribute is assigned exactly one value.

In such a system, it is impossible to correct the existing states. It would be necessary to physically overwrite them, which could cause problems with the consistency and usability of the whole system, whereas the states before modification could already be used for reports, analyses, and so on. Repeatedly calling these functionalities with the same parameters would achieve different results. However, the reasons for the changes would not be directly identifiable, as individual...

Temporal system requirements

The requirements for temporal systems were first summarized in the book Managing Time in Relational Databases by Tom Johnston and Randall Weis. They presented the first two aspects – usability and performance. Based on our own research, we’ll extend the definition to the rest of the aspects. The main reason for the extension is to ensure complexity and describe in detail the temporal approach used:

• Usability: This focuses on the ease of use of methods for users. The aim is to provide a robust and easy-to-use solution, regardless of whether we access currently valid records, historical data (images of objects that were valid in the past), or records that will become valid in the future, but information about these states is already stored in the database. This aspect also focuses on the possibility to monitor changes, perform statistical evaluation, and create a platform by providing input data for decision-making.
• Performance:...

Exploring temporal dimensions

Time can have various meanings and representations in temporal database systems. It does not have to be just about validity; the time when the insert statement was actually executed, processed, or approved can be referenced. There is no complex formulation and categorization of individual time aspects in current systems and the literature overview. Modeling and interpretation are mostly left to the developers or system admins. Therefore, we will summarize the main principles and reference models in the upcoming subsections. You will understand that it is not enough to refer only to validity; we need to create a platform for recording state corrections over time or solving synchronization across multiple nodes. For example, we may have a state that we consider to be valid for a certain period of time. However, it is possible that later we discover that this state was not actually correct and needs to be corrected. Or perhaps, the valid state recorded in...

The attribute-oriented approach

An object-level temporal solution is a relevant solution if the changes are synchronized and occur simultaneously. Thus, frequency, as well as the completeness of the change, must inevitably be synchronized too. Otherwise, duplicate values will be present, resulting in performance degradation and rising disc storage costs. This is caused by the primary key extension dealing with the time elements expressing various characteristics, mostly related to the validity frame. The opposite of object-level temporal granularity is associated with the attribute itself. Therefore, each attribute is treated separately, providing robustness with an emphasis on the different granularity and frequency of the changes. As a result, a particular system can cover any attribute in the core table:

• Static attributes are not changed at all. Once they are initialized, there is no possibility of change. The existing set can be extended by adding new elements (if approved...

The group-level temporal system

Temporal system input data is usually produced asynchronously. An attribute-oriented system provides a suitable solution. On the other hand, it is often possible to encounter cases of synchronization, or partial synchronization of individual attribute changes. Subset data (from the same source) is provided synchronously in batches. In this case, the physical change is divided into individual attributes, which are processed separately for each attribute by writing a new record to the temporal layer. For these purposes, an extension of the attribute-oriented approach to the management of synchronization groups (temporal groups) was created in 2017. It creates an architecturally new solution, expands the possibilities of temporal systems, and ensures efficiency, robustness, reliability, and performance in an environment of partial synchronization of temporal state changes.

Figure 11.11 shows the data flow. For simplicity, we consider only current and...

Conventional table with time-delimited attributes

The fact that a table consists of DATE or TIMESTAMP data type attributes does not automatically mean a temporal table has been composed. The main difference between conventional and temporal tables is the primary key definition and the ability to store multiple versions. The primary key of a conventional table consists of the object identifier (it can be composite). By adding temporal attributes to be part of the primary key, a temporal table can be created. To explain issue, let’s create a table dealing with personal data (PERSON_TAB) by referring to the employment contract table (EMPLOYEE_TAB). Despite the fact that the employee table contains time durations as represented by the start_date and end_date attributes, we cannot talk about a temporal model for several reasons. The first problem is that the time interval does not denote the validity of the record itself; it just signifies the length of the employment contract. Another...

Summary

This chapter forms a crucial part of the physical implementation of temporality. You navigated through the object-level temporal architecture based on the primary key extension. Attribute granularity is formed completely differently. Instead of storing the whole state, only changed attributes are listed. The general solution applied between the attribute and object level is defined by temporal groups, which are composed dynamically and delimited by the group validity. Synchronization groups can be detected and processed as one attribute, decreasing the demands and requirements of the temporal reference layer. In principle, the attribute itself, as well as the whole object, can be covered by a group.

Each temporal state deals with the object reference, as well as the time dimensions, mostly expressing validity. The uni-temporal solution uses one dimension for the temporality while bi-temporal models use two, commonly expressing validity and transaction references. In this...

Questions

1. Choose the correct statement related to the header-temporal concept:
   1. It cannot manage references using primary and foreign keys.
   2. The header consists of the current valid data; the temporal layer is used just for the history.
   3. Future valid data cannot be managed by it.
   4. The header layer is used for the references; attribute values are stored separately in a temporal manner.
2. Which model does not use temporal management?
   1. A conventional model
   2. A uni-temporal model
   3. A bi-temporal model
   4. A fixed temporal model
3. Historical states can lose their importance and relevance by being removed from the main system or moved to an aggregated data warehouse repository. Which aspect characterizes these options?
   1. Relevance
   2. Transaction support
   3. Limited temporal usability
   4. Correctness
4. How many dimensions are covered by the IPL model?
   1. 1
   2. 2
   3. 3
   4. 4
5. Which system takes the validity for each column separately to optimize the storage demands if the frequency rate of the changes for individual attributes is not...

Further reading

• Concept of temporal data retrieval: Undefined value management by Michal Kvet, Štefan Toth, and Emil Kršák discusses the complexity of the temporal data retrieval process in the temporal environment, focusing on undefined value management: https://onlinelibrary.wiley.com/doi/epdf/10.1002/cpe.5399

• The Complexity of the Data Retrieval Process Using the Proposed Index Extension by Michal Kvet and Jozef Papán deals with an index extension to ensure the performance of the select statement. The performance optimization techniques are based on limiting migration rows, post-indexing, data pointer reflectors, and priority management by introducing architecture enhancements. It is published in the IEEE Access journal and is open-access: https://ieeexplore.ieee.org/document/9763539