Skip to Content
author's profile photo
Former Member

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

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

Add comment
10|10000 characters needed characters exceeded

  • Follow
  • Get RSS Feed

2 Answers

  • Best Answer
    author's profile photo
    Former Member
    Oct 02, 2005 at 01:57 PM

    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

    Add comment
    10|10000 characters needed characters exceeded

  • author's profile photo
    Former Member
    Oct 02, 2005 at 02:06 PM

    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).

    Add comment
    10|10000 characters needed characters exceeded