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).

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.

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:

OneData provides the following column qualifiers for start and end dates:

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.

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.