Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 

We all know that BW Cubes are based on extended start schema. The extended star schema is a more updated version of Classic Star Schema where the Dimension Tables in place of keeping actual data within them , keep SID values. These then further refer to the Master Data SID Tables (S,X,Y).

This keeps the actual Master Data values out of the limit of just one cube and is then available to multiple cubes.

But, how Navigational Attributes are placed in this Extended Star Schema Model. Also, when we talk about Navigational Attributes we do understand that too much of the same is not good for performance point of view. But how...this the million dollar question?

Let us first see one illustration below, this focusses on only one of the many master data connections (any one of them) and which is connected to any of the Dimension Table. We have not considered time dependent Navigation Attribute here.

Suppose the master data here is "Customer Master" data. This is not time dependent and has three attributes within marked as Navigational attributes.

We again focus for illustration on one of the objects "Partner" which is again a master data object with certain other objects as Navigational Attributes.

This makes SID table for both these objects (Customer & Partner) as X table.

Now as we see if we have any object marked as Navigational in any masterdata we end up generating:

  • SID field entries for them in Naviagtional SID Table (X or Y)
  • We have additional joins here which increase complexity (the blue table connections)

So think about how many additional such connections SIDs for one Master Data if we have so many objects marked as Navigational Attributes.

Hope this puts some light on the same  :smile:

2 Comments
Labels in this area