A BW Staging Cube is nothing special; it really is just a normal cube. There is nothing really different about it, structurally or functionally. So why then, does it get a special name?
It is called a Staging Cube because of where it is located within the Layered Scaled Architecture (LSA). Cubes are generally used up in the Consumption Layer (Last) for Reporting. A cube that is used in the Staging Layer (First) or Transformation Layer (Middle) as a replacement for a DataStore is referred to as a BW Staging Cube.
A DataModel with a Staging Cube usually comes to life because of the 16 key field limit of a DataStore, where the record contained more than 16 characteristics that uniquely identify the full key. This typically popups up when dealing with Planning DataSets. A DataStore could not have been used as the incoming records would have overwritten each other, corrupting the integrity of the DataSet.
“the limited data consumption options of using
a Staging Cube are ultimately not worth its use”
BW Staging Cubes come to life because they are the first, easiest solution to solve the DataStore 16 key field limitation. Unfortunately this also removes the benefits of having access to a flat table structure that a DataStore offers.
Given that a DataStore is the right tool for the job of ‘Staging Data in all Non-reporting Layers’; all BW Developers should take the time to explore alternative DataModeling techniques which allows a DataStore to technically have 16 fey fields but still accurately store a DataSet with more than 16 key fields (from a business point of view):
Solution: Implement a Staging DataStore using ‘Concatenated Characteristics’.
Further Reading: Discover why ‘Data Staging Cubes Are a Bad Idea’.