Designing Relational Database Systems (Dv-Mps Designing)

Chapter 8

Although many database systems are designed simply to store and retrieve some set of data, the majority are intended to assist in performing one or more activities. These activities are the work processes that the system will support. A work process is simply a set of one or more discrete tasks that together represent some activity meaningful to the organization. "Process a sales order" and "Find a customer's phone number" are both examples of work processes, although they are of very different complexity.

A task is a discrete action, a step in the performance of a work process. The sales order process, for example, might consist of the tasks "Record sales order," "Check customer credit," "Check stock availability," and "Ship order." The process of finding a customer's phone number, however, probably consists of only the single task "Find customer record."

Distinguishing between a task and an activity can sometimes be difficult; the distinction is fairly arbitrary. Drawing the distinction is rather like determining what represents a scalar value in a data model, in which a single attribute in one model might be decomposed into multiple attributes in another. An activity that is treated as a task in one system might be treated as a process in another and then decomposed into separate tasks at a lower level of detail. As it is with the data modeling process, the decision must be based on the semantics of the problem space.

Some systems don't lend themselves to work process analysis. Ad hoc reporting tools, for example, don't support a specific process as much as they support certain kinds of activities. In these instances, it's more appropriate to build user scenarios. These are discussed at the end of this chapter.