After you have identified each business function that your application performs, define additional requirements that affect the:

• Run-time environment of the application
• Implementation of the application

You described the business functions in terms of the business activities required to carry them out. Business functions are also affected by additional requirements. Identify and include in your Requirements Specification the following:

• Information flow
  Describe the information exchanged during the execution of each business function, where it originates, and where it terminates.
• Number of people
  Determine how many people perform each function.
• Frequency
  Determine how frequently each function is performed and when the most people perform the function concurrently.
• Execution time
  Determine the maximum time you are prepared to allow for execution of each function.
• Availability
  AVERTZ processes 3000 reservations each day, and checks out 2500 cars each day. The reservation, checkout, and checkin functions must each take no longer than one minute.
  Specify when the database must be available for the user to do the work and when the user can continue working even if the database is unavailable.
  AVERTZ rental agents always require access to the databases to reserve a car, to check out a car, or to check in a car.
• Processing immediacy
  Specify whether or not the work performed by the business function must be processed immediately when a user executes the function. (Immediate processing requires the user to wait for the application processing to complete before continuing the work.) Otherwise, you can defer the processing work of the application so the user can immediately resume work after executing a business function.
  Although AVERTZ rental agents need processing immediacy for reserving a car or checking a car out, they can defer the checkin of a car. At checkin, the information gathered is for billing purposes and for car inventory purposes. Therefore, the AVERTZ application supplies deferred processing of car checkins in the form of a queued task. This is also useful if the customer does not want to wait for the checkin process to be handled online.
• Flexibility
  Consider the costs of maintaining and changing the application. Specify any future considerations, particularly growth considerations, that may have implications for how the business function is implemented. Take into account the most aggressive long-range business plans for your company.
• Security
  Determine and specify which user will be able to execute which business functions. Describe auditing requirements.
• Usability
  Consider how the business function is performed and by what type of users (or devices) and based on that information, determine the most likely user interface for the application.
  The AVERTZ sample application handles car rentals. The users are car rental agents. They need several simple forms to enter a relatively limited number of data items.

A Requirements Specification takes into account factors that affect the implementation of the application:

• Delegating responsibilities and setting a timetable
• Describing environmental constraints
• Setting up a quality control system

After you analyze each business function and identify additional requirements for each business function, you can identify the following information for database design:

• Entity or entities each business function uses in meeting its responsibilities
  An entity is an object about which you need to maintain data. Examples of entities for a car rental system are the car, the reservation, and the customer.
• Attributes of the entities
  An attribute is an item of data about an entity, describing or characterizing that entity. Examples of attributes for a car entity are the license plate number, the manufacturer name, and the year of manufacture.
• Relationships among the entities
  A relationship is a connection between entities. For example, each customer can have many reservations, while each reservation is associated with only one customer. Therefore, the relationship between customers and reservations is one-to-many (1--M). Though one-to-many relationships are the most common, one-to-one (1--1) and many-to-many (M--M) relationships between entities are also possible.

Entities, attributes, and relationships are established through the database design, based on the Requirements Specification. However, good application design depends upon an understanding of the entities, attributes, and relationships to create proper access to the data.

3.5 Completing the Requirements Analysis

The result of your requirements analysis is a Requirements Specification for use in both the database design and the application design. Appendix A contains a sample template for a Requirements Specification.

Once the requirements analysis is complete and the initial database design exists, the application design moves to the functional analysis described in Chapter 4.

This chapter provides guidelines for determining the transaction processing functionality needed to meet the business requirements detailed in your Requirements Specification. It illustrates how to determine one or more transactions, or atomic units of work, within each business function. It also illustrates how to decide if your application should use distributed forms processing. (An application with distributed forms processing is sometimes referred to as a distributed application.) Use these guidelines to create a Functional Specification in which you:

• Define recoverable units of database work within your application so that if the application fails between steps, the application can recover and the data in the database maintains its integrity.
• Plan the distribution of the forms, application, and databases within the context of your business requirements to best make use of TP functionality.

Appendix B contains a Functional Specification template.

4.1 Identifying TP Functionality

Chapter 3 described how to define the business functions and the business activities comprising those functions, resulting in a Requirements Specification. The process of defining these business functions and activities is essentially linear: for example, describing a series of steps the user takes to carry out the processing of a reservation.

The next step is to relate the business functions to TP functionality in a Functional Specification by identifying one or more transactions within each business function. The focus of this step is modular or matrix-oriented, rather than linear: for example, several business functions may require the same transaction in the course of carrying out the work. Or, a single business function may require repeated use of a single transaction.

Database design is an integral part of this iterative design process. The database design analysis of transactions depends on the application design of transactions. And conversely, the application design of data access depends upon the transaction analysis carried out in database design. This section describes the process of transaction analysis from the point of view of application design.

4.2 Mapping Business Functions to Transactions

As you identify the transactions that relate ACMS tasks to databases, you must differentiate between two types of transactions:

• Database transaction
  A database transaction is a set of updates to recoverable resources within a single file or database.
• Distributed transaction
  A distributed transaction is the grouping of multiple database transactions into a single recoverable unit or logical database transaction.

Database transactions and distributed transactions are both atomic units of work, and must succeed or fail as a whole. They may appear to the user as identical operations, but they require very different design and implementation strategies.

For example, suppose that you and a friend use branches of the same bank in different cities. Your friend writes you a check that you deposit in your branch. If the bank uses one central database for all accounts, your account is credited and your friend's account is debited in a single database transaction. If, however, each branch maintains a separate database for local accounts, a distributed transaction credits your account using one database transaction and debits your friend's account using another database transaction. In both scenarios, the credit and debit constitute an atomic unit of work---a single transaction from the point of view of ACMS.

This manual uses the term transaction to cover both database and distributed transactions, unless the distinction is necessary for the description of a particular design issue.

4.2.1 Determining the Need for Distributed or Nondistributed Transactions

When you describe the organization of your business and the flow of information for each business function, you provide the basis for determining whether you need:

• A single resource manager---for example, for one or more Rdb databases on a single node
• Multiple resource managers---for example, for Rdb databases on separate nodes, or an Rdb database and an RMS file on the same or separate nodes

You determine the number and type of resource managers and their expected interaction from the information supplied about the business functions in the Requirements Specification. With that information, you can design the needed transactions.

At this point, the initial database design should have been completed. You now know whether the information accessed by each business function is stored in one or multiple databases or files. As you map the flow of data for each business function from submitter to resource manager, you determine when to use distributed and nondistributed transactions.

Integral to this process is the determination of whether or not you need distributed transactions. Generally, nondistributed transactions are preferable because distributed transactions are more difficult to design and to control, and because they use more resources. However, in some cases distributed transactions are unavoidable. In other cases, they have advantages which outweigh a similar nondistributed transaction.

The following figures illustrate a range of business organizations, from single-site, single-database businesses to multiple-site, multiple-database organizations. The implications of each type of organization are outlined, particularly from the point of view of distributed and nondistributed transactions.

Figure 4-1 illustrates a single-site business with a single database.

Figure 4-1 A Single-Site Business with a Single Database

This business probably does not use distributed transactions. For example, a retail shop with a single database for inventory uses nondistributed transactions. However, the existence of a single database does not preclude the possibility of a distributed transaction. For example, the use of a queued task with access to a single database requires that the transaction be distributed.

Figure 4-2 illustrates a single-site business with multiple databases.

Figure 4-2 A Single-Site Business with Multiple Databases

A single factory, for example, uses a vertically partitioned database for functional partitioning of the data: parts, customers, and employees. This business may or may not require distributed transactions. Most update transactions probably affect only a single database. However, if some update transactions involve more than one database, those transactions are distributed transactions.

Figure 4-3 shows a business with multiple sites and multiple databases.

Figure 4-3 A Multiple-Site Business with Multiple Central Databases

In this example, the databases are centrally located. Branch sites can access databases in two ways:

• Directly, through remote access to the databases
  The central office uses the databases locally; the branch offices use remote database access.
• Indirectly, by task calling
  Applications at branch sites contain tasks that use procedure servers to call tasks in an application at headquarters. The central office has local access to the database.

Your TP system can include elements both of remote access and of task calling to the central application.

The AVERTZ company uses this model. Section 6.6.2 describes design issues for remote data access.

A similar business organization can use distributed forms processing for an entirely different TP system. Distributed forms processing places front-end forms at the car rental sites and back-end processing at the central databases. Branch sites do not have applications that communicate by direct remote access to databases or by indirect access through task calling to a central application. (See Section 4.3 for guidelines on distributed forms processing.)

A configuration with central databases is easier to maintain and control than one with local databases, but if the central system fails, no application work can be done. However, you can maintain high availability with a VMScluster at the central site. Allow for higher application availability by creating a configuration in which if one central system fails, you can failover to an alternate system.

Note that a similar configuration might include a single central database, rather than multiple databases. While multiple databases indicate the likelihood of the need for distributed transactions, keep in mind that a single database can require distributed transactions if task queuing is used.

Figure 4-4 describes a system with multiple databases at multiple sites.

Figure 4-4 A Multiple-Site Business with Multiple-Site Databases

This model contains the same elements as the multiple-site, central databases model, but adds local databases at branch sites. An example is a bank that maintains local databases for the accounts of regular branch patrons, but also maintains one or more central databases.

Such a system improves performance and allows local application availability to continue if the link goes down, but is more difficult to manage and control than a system with a database or databases in a central location. This configuration is likely to have a relatively high need for distributed transactions. This configuration might also make extensive use of distributed transactions for initiating queued tasks, particularly for ensuring the integrity of distributed transactions if links fail.

These examples do not exhaust the possible combinations of business sites and resource managers. To design the most successful application, take into account the organization of your business and the type and configuration of your resource managers. Consider not only the current organization, but also likely growth scenarios. You can then maximize your design to take best advantage of that configuration.

The AVERTZ reservation processing application that is referred to in this manual stores all of its information in two Rdb databases. The reservation processing information originates at the users' terminals and terminates in a single database, the VEHICLE_RENTALS database. However, a second database, VEHICLE_HISTORY, stores information for auditing purposes. At several places in the reservation, check out, and check in of a car, the following operations must be performed on the two databases:

• Auditing information is gathered from the terminal and the main database.
• Information is added simultaneously to the main database and to the auditing database.

Using a distributed transaction to update these two databases ensures that if the first database transaction succeeds and the second database transaction fails, the first is rolled back.

In such a scenario, the use of multiple databases mandates a distributed transaction. Figure 4-5 depicts the data flow for this distributed transaction.

Figure 4-5 Determining Data Flow for Business Functions

You may identify transactions that do not need to be processed immediately, or that are better left for later processing. In this case, even if your application requires only a single database you may need to design one or more distributed transactions. You do this by designating a distributed transaction that includes both the database and the task queue as resource managers (if you need to coordinate the enqueue or the dequeue of the queued task with modifications to the database).

Queuing allows your application to:

• Defer processing work and allow users to immediately continue working after selecting a task

• Keep applications available to users when the back-end, processing node is unreachable
• Provide automatic retry of queued tasks that have failed

  Note When DECdtm is used, the ACMS QTI ensures that queued tasks are processed only once (without any programmer intervention, which was required in versions of ACMS lower than Version 4.0 to achieve this effect).

See Chapter 6 for details about designing distributed transactions that include queuing.

Chapter 6 also describes the use of queuing for distributed forms processing in applications which use a front-end node for data entry and then queue tasks for processing by a back-end node. When both nodes are available, the back-end node processes queued tasks at regular intervals. If the back-end node goes down, the front-end node continues to queue tasks, providing users with uninterrupted access to the application for entering data on the front-end node. The tasks remain queued until the back-end node becomes available for processing.

Using the DECdtm transaction services and an ACMS queue file marked for recovery unit journaling, ACMS guarantees that changes made to a database by a queued task are committed only once.

4.2.3 Defining Transactions to Avoid Lock Contention

In TP systems, locking is a necessary control technique for regulating concurrent access to shared data in a database. Because multiple users concurrently access a shared database in a TP system, locking issues are of great importance when designing TP applications. The goal is to design the smallest possible transactions---the smallest atomic units of work---to allow quick release of servers and maximum access to records.

You must often segment a business function into multiple transactions to minimize lock contention. While User A updates Record A, the record is locked. User B must wait for User A's transaction to finish before updating Record A.

Figure 4-6 illustrates locking from the point of view of two users needing access to the same record in a database.

Figure 4-6 Record Locking

ACMS allows you to retain context if you need to retain record locks between processing steps. Because both Rdb and DBMS support only a single active recovery unit in any one server process at a time, server context is always retained within the bounds of a distributed transaction. Server context includes:

• Record locks
• File pointers or currency indicators
• Other process characteristics

Retaining server context can adversely affect performance both by withdrawing the server from use by other task steps, and by handling a transaction that holds locks on databases across steps, thereby blocking other users from the records that are locked.

4.2.4 Identifying Transactions Within Each Business Function

Keeping in mind the issues of lock contention and of distributed and nondistributed transactions, this section offers guidelines for identifying the transactions related to each business function.

Consider the following in deciding when to have a specific operation or set of operations execute within the bounds of a transaction:

• Specify transactions when operations change data in a file or database.
  Locking a record ensures that no one can change the record while you are updating it. Otherwise, users trying to get access to the same records must wait for transactions to complete before they can do their work. Record locking is automatic when you use Rdb. Lock only the records that are changing.
• Do not include exchange steps within the bounds of a transaction.
  Lock duration affects performance. If you design a transaction to include exchange steps, you maintain the record lock throughout the time it takes the terminal user to respond. This can greatly increase transaction time over the time necessary for execution of data manipulation statements alone.
• Avoid unnecessary read operations within the bounds of a transaction.
  Operations that only read data from the database and display it to the user do not require record locks. A lock held across a read operation in a transaction is not likely to be as costly as one held across an exchange step, but still has some cost. For example, a transaction consisting of a database update followed by a read, followed by another update locks all the records. If the read is lengthy, lock contention can become serious.
• Make transaction units as short as possible.
  Because resource managers do not release record locks until the transaction is committed or rolled back, keeping transaction units short reduces database contention and ensures better application performance.

Table 3-3 listed business functions and the specific business activities within each business function of the AVERTZ Company's reservation processing. This section identifies the transaction processing transactions associated with each AVERTZ business function. (Chapter 5 describes the parallel process of identifying the ACMS tasks associated with each AVERTZ reservation processing business function.) Table 4-1 lists the business functions and their related transactions. Note that a transaction may be used in one or more business functions.

Table 4-1 Business Functions and Sequence of Transactions in the AVERTZ Reservation Processing Area

Business Function	Step	Transactions	Read Update	Dist?	Database
Reserve a car	1	Find a site	Read	No	VEHICLE_RENTALS
	2	Read existing information about the customer	Read	No	VEHICLE_RENTALS
	3	Update the customer information	Update	Yes	VEHICLE_RENTALS, VEHICLE_HISTORY
	4	Write the reservation	Update	Yes	VEHICLE_RENTALS, VEHICLE_HISTORY
Check out a car (at reservation time)	1	Find a car	Update	No	VEHICLE_RENTALS
	2	Update the customer information	Update	Yes	VEHICLE_RENTALS, VEHICLE_HISTORY
	3	Complete the checkout or cancellation	Update	Yes	VEHICLE_RENTALS, VEHICLE_HISTORY
	4	Write the checkout or cancellation history	Update	Yes	VEHICLE_RENTALS, VEHICLE_HISTORY
Check out a car (not at reservation time)	1	Read existing information about the customer	Read	No	VEHICLE_RENTALS
	2	Update the customer information	Update	No	VEHICLE_RENTALS
	3	Find a car	Update	No	VEHICLE_RENTALS
	4	Complete the checkout or cancel	Update	Yes	VEHICLE_RENTALS, VEHICLE_HISTORY
	5	Write the checkout or cancellation history	Update	Yes	VEHICLE_RENTALS, VEHICLE_HISTORY
Check in a car	1	Read existing information about the customer	Read	No	VEHICLE_RENTALS
	2	Update the customer information	Update	No	VEHICLE_RENTALS
	3	Find the rental history	Read	No	VEHICLE_RENTALS
	4	Complete the checkin	Update	Yes	VEHICLE_RENTALS, VEHICLE_HISTORY