Temporal Objects Rules and Restrictions
Temporal objects are data objects that are time-variant. Typically a temporal object has a start date and end date that limits the time during which the record is valid. To use the temporal object functionality and to prevent two records from overlapping, either the start date or the end data should be defined as part of the primary key, for example a concatenated key of the record ID and the date. Temporal objects can behave differently based on how the object is configured. For example, temporal objects can be configured to limit valid records to only a specific time period, where:
The effective start date is in the past (using the column qualifier,
Retroactive Start Date) but, the expiration date is in the future only (using the column qualifier,
End Date).
The effective start date can be only a future date (using the column qualifier,
Start Date).
The same record can appear multiple times with different effective date ranges that cannot overlap.
On the Filter tab, you can filter temporal objects using the can be filtered using “as of” date field records.
The effective dates of records in temporal objects must comply with the logical rules regarding the record’s life. For example, if you are entering a record with a start date or end date that is prior to the system date, you must use the column qualifier Retroactive Start Date or Retroactive End Date.
When records are part of a hierarchy, the effective dates must meet the constraints of the hierarchy. For example, a child record can only be effective within the effective dates of the parent record, and not before or after the parent record’s effective dates.
When records are added to the hierarchy, the order in which the relationship is established between records determines the order in which effective dates are entered in the child record or the parent record.
If you create the parent record before you add a relationship to a child record, you must define any effective dates in the parent record before defining the effective dates in the child record. When you later establish the relationship to the child record, the corresponding effective dates of the child record must be defined (cannot be null) and must fall within those of the parent record (where dates are defined for the parent):
The start date of the child record must be on or after the effective start date of the parent record and
cannot be null.
The end date of the child record must be on or before the end date of the parent record.
If you create the child record and then establish a relationship to a parent record, you must first define the effective dates in the child record before defining the effective dates in the parent record. The effective dates of the parent record must encompass the effective date range of the child record’s effective dates:
The parent record’s start date must be on or before the child record’s start date.
The parent record’s end date must be on or after the child record’s end date.
OneData provides the following column qualifiers for start and end dates:
Start Date: Defines the start date of the record. This date must be on or after the system date.
End Date: Defines the end date of the record. This must be after the start date and after the system date. If the column has the
Column Qualifier set as
Non-editable after end date, the record becomes non-editable after the record end date. For more information about the column qualifiers, see
Implementing webMethods OneData.
Retroactive Start Date: Defines the start date of the record as beginning prior to the system date. This qualifier is used for historical tracking.
Retroactive End Date: Defines the end date of the record as ending prior to the system date. This option is used for historical tracking. The record can still be modified if the
Retroactive End Date is before the system date.
Non-editable after end date: Defines the record as un-editable after it expires.
Note: The parent child temporal validations can be skipped by setting an option in the object definition. For more information on skipping temporal validations, see Implementing webMethods OneData.
For more information on temporal objects, see
Implementing webMethods OneData. For information about defining temporal objects in Default mode, see
Inserting Records into Temporal
Objects. For information about defining temporal objects in Nova mode, see
Inserting Records in Temporal
Objects.