SQL Server OLAP - back to basics for Cube access from front-end application?

One of the [SSP] forum user asked about what is OLAP, how the process flow occurrs when update happens to a fact table!

It sounds like the basic question for Analysis Services user, OLAP - On-Line Analytical Processing for BI - Business Intelligence is useful for a fast and interactive access to aggregated data and the ability to drill down to detail, such an useful for Marketing/Sales personnel. SQL Server OLAP engine works on the performance by letting the users view and interrogate large volumes of data (often millions of rows) by pre-aggregating the information. Cubes and Fact tables are common table layers on the backgrou that puts the final data-presentation needed to make strategic decisions directly into the hands of the decision makers, not only through pre-defined queries and reports, but also because it gives end users the ability to perform their own ad hoc queries, minimizing users' dependence on database developers.

Basic layer of OLAP leverages data from a relational schema (data source) by using key performance indicator (measures) into the data-context (dimensions) that will process into multi-dimensional database (cube). All the indicators for performance are pre-loaded and aggregated when a data retrieval is initiated, a significant performance difference compared to relational database. Such in a state the processed cube can then be made available to business users who can browse the data using a variety of tools, making ad hoc analysis an interactive and analytical process rather than a development effort. Between the SQL Server version such as 2005 and 2000 the BI suite has a substantial improvement in terms of performance, management & capability. 

In this case the process flow for the OLAP application involves another layer of table-access (that is referred in the Technet documentation) ...one of which is by providing the capability to temporarily or permanently write values back to a set of cells within a cube. This capability, called cell writeback, supports strategic planning by facilitating interactive "what if" analyses. You can temporarily write values to a cube and examine the resulting aggregations locally, without actually changing data on the Analysis server. Once you have completed your planning activity and have a useful set of values, you can permanently write the values to the cube.

Permanently writing a value to a leaf cell in a cube requires an individual writeback operation, which writes a single record to a writeback table. However, permanently writing a value to a non-leaf cell can require hundreds of thousands of individual writeback operations, each of which writes a single record to a relational database. The value for a non-leaf cell must be allocated across all of the leaf cells that are subordinate to the non-leaf cell, and then the values of the leaf cells are aggregated to provide the value of the non-leaf cell. Because this process can require a high volume of individual transactions, permanent cell writeback operations can significantly affect the performance of the underlying relational database.

Further  information on the internals and operations of OLAP within BI look at  http://sqlserver-qa.net/blogs/bi/archive/2007/07/03/sql-server-2005-analysis-services-operations-guide.aspx post too.