The foundation for Intranet business applications is the database. The database is responsible for storing information until the system requires it. In particular, it stores the persistent state of all aspects of the business system. Among the different types of databases, two important types are the relational database and the object-oriented database. The relational database stores data elements in a table that has rows and columns. Each table has a column or columns that serve as the key to locate the data, for instance a customer's account number. The object-oriented database uses arbitrary pointers to relate objects to each other. This more abstract approach offers a performance advantage for some applications. However, object-oriented databases tend to be less flexible for ad hoc reporting.

Skillful design of the database through the process of normalization allows the database to handle data requests and reports not anticipated during the initial design of the system. Normalization within a relational database involves breaking the grouping of data elements from what may seem like natural groups into smaller groups that can be reassembled in various ways, as required by the applications using the database. There is a natural tension between normalization of data and performance optimization.

Many Intranet business applications use a transaction monitor to partition access to the database to enhance performance and scalability. The transaction monitor provides an information highway that can span multiple computers. Servers publish the services they offer through the transaction monitor. Clients can request a service without knowing where the server runs. The transaction monitor provides transparency of location.

To enhance performance, it is possible to have many servers, each offering the same set of services, but through a single queue managed by the transaction monitor. Requests are submitted to the queue, and the transaction monitor routes the requests in order to the next available server. This is comparable to the single line in a bank with multiple tellers serving the line. Unlike the supermarket model of one line per clerk, the user does not risk getting stuck behind someone with a large request. System operators can start additional servers to handle the load if required or shut down servers as the workload mix changes.

Figure 7. Single Queue, Multiple Servers

An important attribute of these servers is that they must provide context-free services or stateless services. Just as in the single-line multiple-tellers bank model, in which every teller must be able to provide the same services for those waiting in line and in a single visit, so too the services and servers must be designed to handle requests in a single contact. The client must bring enough information along with the request, and the server must be able to access the rest of the information required to handle the request.

Many systems employ a single computer for the database server. To achieve the performance larger systems require, three different configurations are often used for this single computer. First is the uniprocessor, a single CPU with memory. In the symmetrical multiprocessors (SMP) configuration, several CPUs share the same memory (see Figure 8). The massively parallel processors (MPP) configuration consists of more than one CPU, each with its own memory (see Figure 9). In the MPP configuration, the operating system typically makes this collection of CPUs appear as a single computing resource.

Figure 8. SMP Computer

Figure 9. MPP Computer

Increasing beyond a single computer on the bottom tier significantly increases complexity in the design and implementation of the system. Generally this involves partitioning the application into cooperating subsystems, each with its own database. Some new database products can span multiple computers to create what appears as a single database.