So far, we have used the term “business state” in a very abstract sense to mean the entire business, and the term “database state” has been used to describe the contents of the
entire database. However, as pointed out in the introduction of this thesis, we rely on individual, pre-existing, visual, state-oriented descriptions of business processes (such as workflows, process models, state charts, etc.) to map out fragments of the business state space onto fragments of the database state space and then constrain the database state space appropriately. In other words, instead of attempting to relate the entire business to the entire database, we restrict ourselves to specific well-understood functions of a business (and the governing policies associated with those business functions).
The reason for doing so is straightforward. A typical business user can understand the broad-ranging assertion that a “business is equal to its database.” However, in practice, the possibly hundreds and thousands of correspondences between various business pro- cesses and individual tables and rows is likely to be beyond the scope of a single user to comprehend. In a typical commercial database deployment, no single user can describe completely and accurately all the complexities in all activities of a business. Similarly, it is equally likely that a single DBA may not be aware of (or be able to explain) the behaviour of all parts of a database as it changes over time. Therefore, instead of attempting to map out two very large and abstract state spaces and then translate rules from one to the other, we reduce these state spaces so that they are more manageable.
Reducing the state space to smaller and easier to understand fragments has several advantages. Foremost, visual descriptions of processes are typically readily available, as they are widely used tools in the businesses and software engineering communities. And even if processes are not fully documented, business users can provide pictorial descriptions of business processes (stages, progression through the use of arrows, branches for various exceptions, termination conditions, etc.) at a very high level, which can then be used as a basis for database constraints. Thus, such descriptions play the role of providing the “business state space” for individual business processes in our model. Furthermore, these process diagrams resemble state machines (see Figure 3.2) and provide significant insight into the valid (required) behaviour of the associated parts of the database. Finally, we note that at the level of individual process/workflow/activity, these descriptions are easy to understand. At the individual process level, the correspondence between changes in the business level objects and database constructs is much easier to capture. Consequently the overall process of translating business rules into database constraints is made much easier
when using one process diagram at a time to guide implementation.
3.3.1
Terminology and Setup
Figure 3.2: A hypothetical process model for expense claim processing describing the stages (states), actors (users) and actions (transactions) related to an expense claim.
Our overall goal is that of translating constraints from the business world to the database world. Our approach, as described above, is to do this one process (business function) at a time. To make our notation consistent, from this point onwards we will use the term artifact type or (business) object type to refer to a concept about which various processes are specified. For example, Figure 3.2 is a simplistic example of a “payment process” on the “expense claim” artifact type. Such process diagrams often embed within them interpretations of the business policy for the process being outlined. For example, a policy rule embedded in the above diagram could be that “only a member of the finance department can issue a payment for an expense claim that is awaiting payment.” Con- sequently, all individual artifacts of that type (all expense claims) must follow the rules embedded in the depicted process. Note that we are using the term artifact as it has been used in prior work1 to mean, broadly, an object of interest to a policy maker.
Similarly, we are using the term process model to represent the large category of visual state-oriented descriptions of operational business specifications, as discussed in Chapter 2. Although these specifications can include a broad range of diagrams, it is best that
1This is examined in greater detail in Section 3.7. The reader unfamiliar with this term can consider
the reader consider these descriptions to be informally specified workflows or flowcharts (such as the example in Figure 3.2). A more rigorous examination of issues and features of process description languages that make them more amenable to conversion into database constraints is presented in Chapter 7. However, for now, the reader should consider them to be informal state oriented diagrams that have to be given formal meaning as database constraints. Therefore, we use the term “policy makers” to refer to users who will convert these informally specified business into database constraints.2
Finally, recall that having these process diagrams is not a strict requirement for con- straining a database system, as long as a detailed explanation of the behaviour of the business processes is available. It is of course helpful if this description is available in visual notation (state oriented and depicting valid progression), as this makes the task of converting process models into database constraint models significantly easier. Clearly, if the business states can be easily identified in the database (e.g., the notion of being in the unpaid business level state maps onto a binary paid flag being zero in the database), then we can begin to reason about paths an artifact can (should) take across the business state and how they map onto restrictions on the database state space. However, we point out that a proficient enough policy maker (who is knowledgeable about a process on an artifact type) may not need to rely on business level process diagrams to embed constraints on a database.