Formal Model

Using terminology that is consistent with prior work [122, 97, 19, 123, 24, 79, 147], we provide a formal interpretation of our policy model that employs temporal integrity con- straints over uniquely identifiable tuples in database views. Since we are considering con- straint enforcement over a temporal database (and temporal objects therein), we assume the presence of the infrastructure to track changes to the attributes of individual artifacts. In our model we consider the domain of time to be isomorphic to a finite set of ordered natural numbers (0, 1, 2, . . . , c), where c represents the current or most recent transaction time. Each artifact has its own finite history that can be considered as a temporally ordered sequence of changes made to the attributes of the artifact since its inception:

Definition 4 (Artifact History). The history of an artifact is a mapping from natural numbers representing time to ordered tuples of the form {(t, a1t, a2t, . . . , ant)}, where each ait is the value of the attribute ai at time t.

Therefore, the history of an individual artifact with n attributes can be considered an ordered sequence of tuples starting at t = 0 (artifact inception) and ending at t = c (current or most recent time). Note that artifact histories are not combined or intertwined in anyway. That is, each individual artifact history (timeline) is retained independent of other histories in the database. We use the shorthand notation of depicting the history of an artifact A as: A0, A1, A2, . . . , Ac. The same can be viewed in its expanded form as follows: A0 : (0, a10, a20, . . . , an0) A1 : (1, a11, a21, . . . , an1) A2 : (2, a12, a22, . . . , an2) . . . Ac: (c, a1c, a2c, . . . , anc) (3.1)

Approaches to maintain individual artifact histories (e.g., auxiliary tables and delta-encoding) are examined in detail in Chapter 4. However, for now we assume that a database is capable of tracking changes to individual artifacts and utilize the above abstraction for constraint enforcement.

As is the case in implemented database systems, the number of attributes of the artifact type, n, is finite and the domains of each of the ai are assumed to be finite as well. Thus, there is always a finite amount of history that is contained in a database for every artifact. Definition 5 (Constraint). A constraint in our model is a Linear Temporal Logic (LTL) formula defined using the attributes of an artifact type but interpreted (enforced) over the history of all artifacts of that type.

All artifact histories must comply with all the constraints defined on their respective artifact types and a constraint on an artifact type cannot be selectively enforced on a few artifact histories only. To specify constraints we use LTL formulas with past connectives

only (Past-LTL). This is a natural choice in database systems, since enforcement decisions can be made with certainty by looking at the past history of an artifact only. The interpre- tation of these constraints (i.e., the enforcement model discussed in detail in Chapter 4) can be summarized as follows: Given an update to an artifact A, we consider the history entry that would be committed to disk if this update were allowed to happen. That is, we check for each artifact being impacted that its anticipated history A0, A1, . . . , Acurrent, Anext is a valid trace for all the constraints specified over A’s artifact type. If the resulting trace is valid, then the transaction is allowed, i.e., Anext is accepted as the new history entry for the artifact, otherwise the artifact stays unchanged as Acurrent.

To accommodate restrictions over different domains, constraints are specified using Constraint Linear Temporal Logic (CLTL) [173, 17, 24, 49, 48, 50]. CLTL extends LTL and adds a spatio-temporal aspect to the logic by allowing constraints to be specified over domains with well-defined operators as propositions in the logic. For example •(x < y) is a CLTL formula interpreted over the domains of x and y and a definition of the operator <. We use traditional operators (<, ≤, =, 6=, ≥,>) for well known (finite fragments of) domains {N, Z, R, Q} to specify constraints. Operators on complex domains, such as (=) on the domain of Strings (varchars in SQL), are used in their intuitive programmatic interpretation (i.e., string comparison). Note that we can adopt this interpretation because our domains are assumed to be finite. Consequently, we can treat database level attribute types (e.g., varchars/strings, floating point) as finite subsets of a well ordered domain, such as Z, and then define operators such as equality to mimic the behaviour of the appropriate database functions.

The definitions of the past LTL operators utilized to constrain the history of artifacts are consistent with prior literature and are as follows:

1. CLTL formulas SA, ¬SA, SS ∧ SB and SA∨ SB evaluate as true iff the conditions, specified as constraints over the appropriate domains, hold true

2. •SA (previously SA) is true at instant t iff t > 0 and SA is true at instant t − 1

3. SA since SB is true at instant t iff for some s, 0 ≤ s < t, SB is true at instant s, and for every u, s < u ≤ t, A is true at instant u.

4. SA (sometime in the past) is true at instant t iff true since SA at instant t

5. SA (always in the past) is true at instant tiff ¬¬SA at instant t

Thus, constraints specified using CLTL are extended LTL constructs and are inter- preted in the same manner as classical LTL constraints. It is important to recognize that constraints are specified over an artifact type but enforced on all individual artifacts’ his- tories of that type. For example, consider the following constraint defined on the sales order artifact type defined earlier:

paid ⇒ •(¬paid ∧ amount > 0)

It forms a temporal constraint using two attributes from different domains (boolean and floating point, as derived from the view specifications). It specifies that if an artifact’s paid attribute is currently true, then it must be the case that previously the same boolean attribute was false and the amount attribute was greater than zero. Note that this con- straint is specified using the attributes of the artifact type and then enforced on all artifact histories.

It is important to recognize that the CLTL constraints are always interpreted over the history that would result as a consequence of the “next” entry being added. That is, a given constraint is always checked over (A0, A1, . . . , Acurrent, Anext). In the above example, if a new entry in the artifact history is being appended (Anext) in which the boolean attribute paid is true, then condition ¬paid ∧ amount > 0 must hold on Acurrent before Anext is allowed into the history. In other words, enforcement is done by continuously monitoring the impact of the next (to-be-written) entry in the artifact history and ensuring that the resulting history is compliant with the constraint specified.

As is common in database systems, we adopt a strict model of compliance, where all the user-specified CLTL constraints on all artifact types must independently hold for all individual artifacts. This is especially relevant to situations where a database transaction modifies several different artifacts at the same time. In such cases we require that each of the individual histories being appended remains compliant with all the constraints defined over their respective artifact types.