Modeling for navigational attributes

[Former Member]

The current modeling that we are working on has the 0DOC_NUMBER to have the nav atributes order reason and purchase order type of the 0DOC_NUMBER. The 0DOC_NUMBER is defined in the DSO.

Should these nav attributes be converted to be part of the transaciton data or left as is?

Will the conversion from the master data to transaciton data be a probelm with the modeling based on the limited dimensions.

We have already 13 dimensions.

[Former Member]

u dont have to cconvert the nav attr into transaction data.when u running the query it the data cames from source system to cube at the time of running the query. so u need not assign the dimension for the navigational attr.

[mathew_muthalaly]

Hi,

An important consideration for deciding this should be whether you require the history of attribute value changes over time. A track of changes would not be available if it is part of master data but would be available if it is part of transaction data.

Mathew.

[Former Member]

You should convert this to transaction data

Every sales document will be having one order reason field and associated purchase document number.It is very much part of transaction data and leaving as it is not the best approach

You can include this order reason and purchase document type field in the transaction data and put them in same dimension as Sales document

Further , you have settings for high cardinality also available in the cube

Each dimension table can have maximum of 248 characteristics ( for your information )

Message was edited by:

SDBI

[Former Member]

you can leave the attributes as it is, it should not be a problem.

[Former Member]

The users want to convert the attibutes of 0DOC_NUMBER to transaction data?

[Former Member]

Hi Edna,

Technically the difference between Nav and display attributes is that when you mark an attribute as navigational system will genrate SIDs for it when you load data. Also it will be referenced through the characteristic so you dont need to put it in your transaction data. You will still be able to drill down on them in your query. Hope this will be helpful.

Sumit

[Former Member]

Hi,

If you already have Nav. Attr. in the ODS (DSO) , its better to keep it as is.

You can convince customer that there is no need to put it in transaction data.

Only if the query performance is affecting due to these nav. attr. that you can think of converting those to characteristics (part of Trans. data).

Any way if you have to convert it, that should not be a problem. But you have to delete and reload complete data for this.

Regards

SSS