Question:
Hi,
We need to get the line items from PCA (about 5 Mil records) and Account-based PA (around 5 Mil records again) into BW.
The ultimate use is for SEM-BPS. The modelling question is do we have to first stage it in ODS or can we put them straight into cube.
There are no special reporting needs. Line items are only for drilldown purposes. No cleansing/transformation that needs to be done before the cube. Plus both the datasources are delta enabled so the ODS-to-cube delta functionality is not a clear advantage. So what are the pros and cons of staging it in ODS before the cube. Ofcourse if we use ODS, we gonna leave out the line item chars when moving it to in the cube. So, the data in the cube would be aggregated and so better performance. But if that is the only real benefit of using ODS, is it worth it when considering additional processing/maintenance and delay in the data loading process.
I read some whitepapers and documentation but would always like to hear first hand experiences.
Thanks in advance.
Answer:
"Ofcourse if we use ODS, we gonna leave out the line item chars when moving it to in the cube. So, the data in the cube would be aggregated and so better performance"
The concept of having line items in cube versus ODS is a completely design issue and you could actually have data on line item level in the cube itself.
In my opinion and through the little amount of experience in BW i can safely suggest staging data in ODS before the cube.
Reasons:
1.You could use one ODS to update multiple Cubes.
2.If for some reason the cube data gets corrupted, you always have a copy of the same data in ODS.(or you need to add a new characteristic in the cube)
I am sure there are many others reasons,gurus like chetan patel and others might be able to shed some light.
3.
Answer:
Dear Vamshi
Taking ur points valid ,Its been discussed couple of times on Forum
Also SAP recommends not to use ODS,though u can store it in Cubes.
Try below link
http://help.sap.com/saphelp_bw33/helpdata/en/a7/d50f395fc8cb7fe10000000a11402f/frameset.htm
Hope it Helps
P.S. Sincere Request not to use words like GURUS ,as we all are in the same Boat its just a matter of hands on
more over Guru sounds OLD person and m still young
I remember CHC mentioning these earlier as well .
_________________
Chetan
@ CP...
Answer:
Chetan,
I had read the link that you posted before and did understand that SAP reccommends ODS for line items. But am not convinced as to the real benefit. So, wanted someone who has used a cube instead of ODS and either is satisfied or regrets the usage to comment.
Also, is there any issue of performance when using ODS with 5+Mil records (with an increase of 2Mil/year). I would not assume since it is for line items but I think I read someone post that there is an OSS note for ODS performance in similar situation.
Thanks.
Answer:
hi sr_fico,
I'm also not convinced by the usage of ODS. In my opinion ODS is not very reliable. We encountered hundreds of probelms with ODS usage. Like activation, reconstruction of packages and so on...
Answer:
I'm also not convinced by the usage of ODS. In my opinion ODS is not very reliable. We encountered hundreds of probelms with ODS usage. Like activation, reconstruction of packages and so on...
i strongly disagree! ODs can be very handy to stage and manipulate your data in different levels.
Moreover, the data is contained in real flat tables, whihc makes it easy to do real hard coded modifications on (i know, not the standard way , but believe me : i've been very happy in the past that i could do this).
In my opinion, SAP doesn't stress the advantages and usage of ODS's enough...
Do not underestimate the power of ODS's
Answer:
In a cube this size I would not hesitate to include a document line item dimension, especially if it will be required frequently. E.g. SAP include one (SUID) in the detailed OLAP cube for BW statistics. A base aggregate that excludes the dimension will address any concern about impact on query performance.
An ODS is particularly useful when you need to access multiple attributes at the line item level. If you only need the document key I'd include it in the cube. This doesn't exclude the use of ODS too, I agree with TFR, it is often useful to be able to go back to the atomic data.
Often the need to identify individual documents only applies to recent data, so for larger cubes, you might consider separating the cube into recent (with document id) and older data (without) combined through a multicube.