OLAP applications sometimes handle very large amounts of data, and they usually use multiple components across networks, so it is important to get the architecture right. If you do not, the performance could be unusable, and the hardware costs could shoot up to compensate – you might find yourself upgrading servers (processors, memory, disk) and networks, when with a better design, this would not have been necessary. We have found that, regardless of the apparently similar claims made by vendors, there are some remarkable differences between OLAP product architectures and these make a material difference to the applicability of different products for applications.
We define OLAP as FASMI – Fast Analysis of Shared Multidimensional Information. The achievement of each of the five tests in that definition is affected by the architecture. Many OLAP definitions loosely mandate that the system must be ‘client/server’, without saying what that means. You may think the meaning is obvious, because the term has been around for a number of years, and should therefore be well defined. Even if you, yourself, are not an expert, you might legitimately feel that all the vendors understand it well and have implemented it in similar, optimal ways. Unfortunately, this is not true.
It seems that all that has been generally agreed is that all client/server applications have data on a server, connected over a network to a screen plus keyboard in front of a user. Most generalized definitions are vague about where the application processing occurs. This means that some vendors, who do all the work on a client PC, but have the data stored on a network drive, still call their product ‘client/server’. Some bend it even further and call an application ‘client/server’ if the programs are simply loaded on to a client machine from a network drive before execution commences, even if the programs then run entirely on the client, using only local data. On this basis, almost anything running on a LAN, which has some occasional interaction with a network drive, could be called client/server. Conversely, an old host application, which simply has PCs connected as little more than dumb terminals, could equally claim to be client/server.
We do not describe such architectures as client/server.
In our view, there must be some processing on both the client and the server for an application to be described as client/server. For OLAP, we go even further, and only regard an OLAP application as client/server if some OLAP related processing occurs on both the client and the server machines. We do not mandate that OLAP applications have to be client/server, but insist that those which claim to be client/server must pass this test. This means that the simplest Web architectures, with basic HTML displays do not count as a form of client/server, but the more sophisticated Web architectures do qualify. 数据挖掘研究院
You might wonder why we set this test in a more rigorous fashion than many industry watchers and vendors. The reasons are simple and application based: some client/server architectures deliver real user benefits, but are more expensive for the developer to create. Others are simpler to create, but more restricted in their usage. We think that if the term ‘client/server’ is to have any purpose, it should distinguish between these cases. This purpose is lost if client/server simply means that the application involves a network in some way.
However, even within our definition, we have discovered that there are several different approaches used by OLAP vendors. All of these are truly client/server, but they do have different characteristics. Rather than do the analysis in a theoretical way, we have chosen to go back to first principles and classify client/server applications in terms of what user benefits will be delivered.
