Part 2: Flat files and Business Contents: Any issues with this scenario?

[Former Member]

I will appreciate some clarification on the some points made in response to my previous post "Flat files and Business Contents: Any issues with this scenario?"

1.

" ...you’d better analyze those cubes for data redundancy and presence of data you’ll never use. " I will appreciate some clarification on the type of analysis you are referring to. Examples will help.

2.

"If you want to combine several found IOs in your custom dataprovider, then again you must know (or figure out) relationships between these IOs." I will appreciate some clarification on the type of relationship you are referring to. Examples will help.

3.

I am a bit confused with "..include into ODS structure ALL fields required for the cube" but you also noted noted that "...except navigational attributes and chars and KFs that are going to be determined in TRs or URs."

If you exclude ALL these, haven't you excluded all the fields you included in the ODS structure?

4.

"Consider carefully the ODS’ key fields selection. Their combination should not allow data aggregation that you don’t need."

I may be missing the point here, I understand that you need to select the fields which will form the unique ID for the records in the ODS under the Key Field (please correct me if I am wrong with the purpose of the Key Field), but I don't understand the discussion of "aggregation" in the context.

Thanks in advance

[Former Member · Accepted solution]

Hallo

I try to give some exaplanation based on the previous answer.

1. Data redundancy - make sure you do not store the same information. does not make sense to have data redundanty across you Data Warehouse. this is also a cost. just sotre the same information one time if you get all what you need.

2. whatwhever you build you dp, which consist of IO, you need to know with kind of relation (1:1 or 1:n - n:n and so on) exist between them. that will help you when you model you infoprovider. For example I would never pit togheter IO (n:m) in the same dimension if you expect an high number of cardinality. Sometime an IO can be an attribute of another one (depend on relation. For example

Business Partner and his Address. Usually you have a relation 1:1, in this case address is an attribute of BParten and store it in the Masterdata instead then DP

3. Sometime when you load from ODS to CUBE, you can fill some IO (which are in the infocube and not in the ODS)through ABAP routine in TR-Start Routine of Update Rule. Does not make sense to include these IO in the ODS as they are NULL or Blank (the deault value). This can happen when for example, you first load in the ODS (Price and Quantity) and then you calculate Sell price later (Price * Quantity). of course it could be doen also in the Bex. Depends on other factors (Performance - Loaidng -Sizing)

4. Make sure that the KEY definition of ODS is accordingly to the data otherwise you will aggregate the data and later maybe if you need the detail you miss it.

for example: customer - product - Distr Chan - Sell Price

if each Customer can buy each product for any Distrution Channel, then when you build your ODS(Customer - Product and Distribution must be KEY) otherwise (if you have only Customer - Product KEY for example) you will lose the details for Distribution Channel.

I hope eveyrhting is clear

Regards

Mike

[Former Member · Accepted solution]

Thanks Mike, you did it!

The problem is now me! I need to find a way to understand the example you provided in 4. I think my issues lie in that example although with my first read I did not understand.

[Former Member · Accepted solution]

Hi Amanda,

As an example to p. 4 see here:

Best regards,

Eugene

[Former Member]

1) The business content cubes may contain IO's that you do not need at all. If you do not remove them they will be filled and take up costly DB resources.

2) Certain IO's need certain UNIT or CURRENCY fields. You must design you info-objects (preferably) that they all use the same units. Otherwise they are difficult to combine.

3) If in the cube you need 0MATERIAL then you will want to include this IO in and ODS as well. If in your query you will need 0MATL_GROUP (attribute of 0MATERIAL) you can determine this IO as a navigational object from 0MATERIAL. In this case you do not need to include 0MATL_GROUP in your ODS.

4) If you have a key 0PLANT 0MATL_GROUP and you have 0MATERIAL as an attribute in your ODS: You will lose detail on the material level since two materials from the same material_group will be aggregated (the key figures will be added together).