An awareness of time is the defining feature of a temporal database. Rows with transaction-time columns are automatically tracked in time by the system, starting from the time the row is first inserted in a table. Rows with valid-time columns specify the period of time for which the information in the row is considered to be in effect. Whenever a row in any type of temporal table is modified or deleted, the system automatically timestamps the row and any new rows that are created as a result of the modification. These timestamps note the time of the change, and are used to close rows with a transaction-time column, and modify the PV as appropriate for rows with a valid-time column.
For example, if a row has a valid-time period that extends from last week to next week, and during that period a change is made to the row, the original information in the original row ceases to be effective at the time of the change. Consequently, the database timestamps the end bound of the valid-time column with the time of the change, because that marks the time the original information in the row is no longer valid. The database automatically adds a copy of the row to the table, having the changed values, and timestamps the valid-time period to begin at the time of the change. The new row retains the ending bound of the valid-time period from the original row.
Because transaction time and valid time are fundamentally different time dimensions, with different purposes in temporal tables, timestamps are calculated differently for transaction-time columns than they are for valid-time columns.
When a row is added to, or modified in a temporal table with transaction time, the system automatically timestamps the transaction-time column to indicate when the system became aware of the new or modified information in the row.
By default, the timestamp used for transaction-time columns is the value read from the system clock by each AMP at the instant the row is inserted or modified. This value is referred to as TT_TIMESTAMP throughout this book:
This automatic timestamping process produces different timestamps for each row within the same load job, and for each row within the same transaction. That means that all modifications, even those within a single transaction, are individually tracked by the database for tables that have a transaction-time column. For example, a transaction consisting of two statements, where one statement inserts a row and the other statement deletes the previously inserted row leaves a track in the database in the form of a stored history row that is closed in transaction time, and unavailable to most SQL.
If a single modification to a row results in multiple rows being automatically added to the database, the system uses the same TT_TIMESTAMP value to timestamp all affected rows. For example, an update to a row of a table with a transaction-time column could result in an update to the original row, plus the insertion of one or two new rows. In this case, TT_TIMESTAMP would be the same time for all rows. For examples of how a modification to one row can result in one or two additional rows being added to the temporal table, see “Sequenced Updates” on page 169.
Note: The granularity of transaction-time timestamping can be changed by means of the SET SESSION TTGRANULARITY statement. For more information, see “SET SESSION TTGRANULARITY TO” on page 106.
A valid-time column specifies the period of time for which the information in a row is effective. Because this information models the real world, such as the period for which a contract is valid:
Although the PA and PV can be explicitly specified for operations on tables with valid-time columns, Teradata Database will use default values if these periods are not specified. For valid-time tables, the current time at the time of a row insertion or modification is timestamped as the value of the built-in function TEMPORAL_TIMESTAMP, or TEMPORAL_DATE if the valid-time column has a DATE type.
The value of TEMPORAL_TIMESTAMP or TEMPORAL_DATE for a transaction is the time or date when the first non-locking reference is made to a temporal table, or when the built-in function is first accessed during the transaction.
For more information on TEMPORAL_TIMESTAMP built-in function, see SQL Functions, Operators, Expressions, and Predicates.