SSAS 2008 Unleashed - Chapter 3. Architecture and Databases: An Overview

Chapter 3. Client/Server Architecture and Multidimensional Databases: An Overview

The architecture of multidimensional databases in many respects follows the design of relational databases. Similarly to relational databases, Microsoft SQL Server Analysis Services supports a variety of architectures for accessing data:

• Two-tier architecture, in which data is stored on the server and moved to the client in response to a query

• One-tier architecture, in which the data is stored on the same computer as is the client application

• Three-tier architecture, in which an Internet server sits between the database server and the client

  Note

  We’ve used the term tier to describe these architectures. We use this term to describe physical layers—components of each layer are separate applications and can even run on separate machines. If you choose to look at the tiers as logical ones—layers of protocols between components—you would get different numbers of layers (tiers).

  
  

• Four-tier architecture, in which data is stored in a relational database, cached in a multidimensional database, and an Internet server facilitates communication between the multidimensional database server and the client

  Note

  You could view a relational online analytical processing (ROLAP) system as a three-tier architecture, too. In that case, OLAP server is middle tier between a client application and data stored in the relational database.

  
  

Two-Tier Architecture

In the most common architecture, represented in Figure 3.1, data is stored on the server, and the client application uses queries to access that data. This two-tier architecture is characterized by simplicity and effectiveness because there is a direct connection between the server and the client, with nothing in between.

Let’s look at each separate component in more detail. The server software receives a request from the client. It processes the request and formulates an answer based on the data located on a hard disk or cached in RAM. In our architecture, the client and the server use the XML for Analysis (XML/A) protocol to send and receive data. The client application can use various object models to interact with the client, which in turn uses XML/A to connect to the server. You can find detailed information about connecting the client application to the server in Chapter 31, “Client/Server Architecture and Data Access.”

XML/A, as is obvious from the name, is a protocol developed for communication with analytical data providers. It has received wide support in the industry, and has obtained the status of a standard. You can find more information about XML/A in Chapter 32, “XML for Analysis.”

The object models we use for administering the multidimensional database are Decision Support Objects (DSO) and Analysis Management Objects (AMO), discussed in Chapter 34, “Analysis Management Objects.” For data access, we use OLEDB for OLAP, ADOMD, and ADOMD.NET. You can find more information about these object models in Chapter 31, “Client/Server Architecture and Data Access,” and Chapter 33, “ADOMD.NET.”

One-Tier Architecture

The simplest architecture (one-tier) is illustrated in Figure 3.2; it’s commonly known as a local cube. In a local cube, the multidimensional database becomes part of the client application and allows access to multidimensional data located on the hard disk of the client computer.

When you have both the cube and the client application on the same computer, you don’t need a network protocol to move data from one to the other. We use XML/A to communicate between the client and the local cube. And the application has the same choice of object models for administering the database as for accessing the cube data.

One drawback to the local cube architecture is that your computer must have enough resources to hold all that data along with the client application, and the power to make the calculations required by the queries to the cube.

A local cube, otherwise known as one-tier architecture, frees the user from the network—a handy arrangement when traveling and unable to connect.

Three-Tier Architecture

Once the Internet gained wide usage, a different architecture to make the most of its advantages was needed. Three-tier architecture, illustrated in Figure 3.3, is the solution that has been established.

With this architecture, the client establishes a connection over HTTP with an Internet server, which then connects to the OLAP server. The OLAP server, usually located on another computer, sends the response data to the Internet server, which prepares the data for client consumption in the form of web pages.

The client application can use the same object models for administering the database and for accessing data as a client application in the two-tier architecture. In addition, a client application can use web pages and HTTP for those purposes.

In a three-tier architecture, an Internet server acts as a middle tier to connect the client application to the OLAP server. Analysis Services uses Microsoft Internet Information Services (IIS) as the Internet server.

Four-Tier Architecture

In the four-tier architecture, illustrated in Figure 3.4, the data is stored in a data warehouse that includes both a relational database (in our case, SQL Server) and a cache of multidimensional data (Analysis Server). After the response data is converted into web page format on the Internet server, the data is returned to the client.

With the data warehouse, we need some way to connect the relational database and the multidimensional database. In addition, we don’t want to have to worry about whether the data needed by the query is in one or the other. Here we find the Unified Dimensional Model (UDM) useful.

Briefly, UDM manages the request for data, taking the needed data from the multidimensional database or moving it from the relational database to the multidimensional. You can find more information about UDM in Chapter 1, “Introduction to OLAP and Its Role in Business Intelligence.”

XML/A, the various object models, and HTTP are used in four-tier architecture in the same way they are used in three-tier architecture.

Distributed Systems

These four architecture systems aren’t the only ways to build multidimensional database systems. There are a variety of systems for distributed storage of data inside a multidimensional database.

Distributed Storage

The following list describes the distributed storage systems that have been developed for Analysis Services as of now:

• Remote partitions— Sections of data are stored on other servers, called remote servers, that are connected to the main computer, the master. Remote partitions make it possible to work with almost unlimited quantities of data.

• Linked objects— A publisher server contains multidimensional data objects (cubes and dimensions), which are mirrored on a subscriber server. The client application queries the subscriber. The referenced objects on the subscriber server initially contain no data, just a link to the data in the original objects. The subscriber server can make calculations in response to a query, and can cache data obtained from the publisher server. Linked objects make it possible to support an unlimited number of users because calculation power can be distributed among many different servers.

These distributed systems provide the possibility of storing and processing practically unlimited volumes of data. We take a closer look at the architecture of distributed systems in Chapter 25, “Building Scalable Analysis Services Applications.”

Thin Client/Thick Client

The variety we find among the different tier systems is just one aspect of the differences we can find in client/server architecture with respect to multidimensional databases. We also find differences in the interaction and distribution of functions between client software and server software.

These variations came about because of two factors. First, the client side today has computational power comparable with the server. This means that the client computer can take on many of the tasks that were previously reserved for the server. The second factor is related to the first. With client computers taking on more of the computational tasks, and data being exchanged over the Internet, customers are concerned with the integrity and security of their systems. In addition, many companies are reluctant to invest in the new software needed to take advantage of the possibilities on the client side.

This dilemma has given rise to two varieties of client/server architecture, known as thin client and thick client:

• A thin client carries out practically no operations besides sending requests to the server and obtaining and unpacking answers. Thin client architecture is popular with Internet applications, where it can be difficult—not to mention inadvisable—to install new software onto the client computers.

• A thick client is able to not only obtain but also cache and process information. This makes it possible to minimize the amount of communication with the server. Thick client architecture is popular in extranet applications, where the network administrator in the company can install additional software at will.

The client for Analysis Services 2000 is a thick client. But, because of the increasing popularity and use of the Internet in enterprise database systems, the client for later versions of Analysis Services became a thin client. Moving to the thin client architecture makes it possible for you to keep all of your data on the server, so that you don’t have to move data around very much to respond to queries. However, you will need more powerful servers to serve the same number of users as you could with Analysis Services 2000.