Reference Characteristic

[Former Member]

Hello,

I have a characteristic infoObject 'Model Name' ZCOPAMDL.

It is a has listed as a 'Reference char.' 0MATERIAL.

When I execute a BEx Query that has both of these infoObjects they get displayed, however both the Key and the Text are different? I though that that data was shared between characteristics that are 'Reference'

When I look at the Text tables in both infoObjects they are exactly the same, so I am confused as to why the displayed key and text is actually different when i run the Bex Query.

Can anyone explain what I am missing?

Thanks,

Nick

[Former Member · Accepted solution]

Hello,

Model Name 'ZCOPAMDL' is created with reference to Material '0MATERIAL'

This means that they share 'metadata' which I interpret as Text/hierarchies.

The problem I am facing is that I don't think that these infoObjects should have been created as Reference.

The reason is that there dataset is going to be different and values will not be in common between the two Objects.

Model Name comes in as a text description of a model (for example: Corolla, Accord, Mustang). Where as Material comes in as more of a technical key (for example: R556608, RWM4433). Since this is how the data arrives in the cube, it is obvious that the values will never be in common, so that is why I think modeling one infoObject as a reference to the other is simply incorrect.

My question is this: Since Model name is coming in with the transaction data, is the model name (for example: Accord, Corrola, Mustang) that arrives with the transaction data being stored in the Text table or somewhere in the Master data, or is it solely in the cube? I ask because both (obviously both, because one is a reference to the other) infoObjects are flagged as having texts and master data, and since it is being recorded in the cube, I assume I should be able to find those values in some infoObject table as well.

Thus my guess is that as my Model Names come in, for example, 'Accord', it is getting added to the master data table as a key, when in fact it is not a key for material, rather it is just a model name that could apply to several materials.

Hmm, can someone clarify for me? (thanks so much for your help thus far)

Thanks,

Nick

[Former Member · Accepted solution]

Hmm... well this is a question of the way the data has been modeled. And seeing the example you have provided, I don't see a cause for having the Model as Reference of the Material.

Your guess: "my Model Names come in, for example, 'Accord', it is getting added to the master data table as a key, when in fact it is not a key for material, rather it is just a model name that could apply to several materials." is correct. This is what is happening, but actually this is not how it should be built up. In this case the Model could be an attribute of each Material.

Hope this helps...

[Former Member · Accepted solution]

Bhanu,

Thank you so much for your help and guidance. I appreciate your confirmation of my suspicions.

I will revisit this data model on my system, as it is pretty clear to me, done incorrectly.

There has not been a negative result, but it is not clean. So I will get to cleaning it up!

Just a recap of what I have observed and learned:

<b>0MATERIAL</b> AND <b>ZCOPAMDL</b> have in common (share) masterdata and text tables. They also have common attributes. This is because when ZCOPAMDL was created it was created as a 'Reference Characteristic' to 0MATERIAL.

In my Cube, both 0MATERIAL and ZCOPAMDL come in with transaction data as characteristics. The data that arrives as transaction data gets stored in the cube.

Because of the fact that only the values that come in as transaction data get stored in the cube, I can run a query against the cube with just those characteristics to get an idea of what Masterdata values have actually been stored within the cube.

I can then look at the master data tables for either infoobject (it doesn't matter which one, because they share data).

Within the Master Data tables I will see even more values for these infoObjects then I see in the Cube. This is because the respective transaction value stored in the cube will also automatically be stored in master data.

Since these InfoObjects can be used in other InfoProviders, the master data table which they share will have a broader range of values. The broader range of values is due to the fact that as transaction data comes into other infoProviders for these infoObjects it is stored in the other infoproviders as local transaction data as well as more generally available in the master data tables.

In my situation <b>0MATERIAL</b> and <b>ZCOPAMDL</b> were incorrectly created as reference characteristics. 0MATERIAL has a more technical name, while ZCOPAMDL has a more readable name. Thus since there dataset is logically not in common, it should not be modeled "with reference" (Reference Characteristic).

Even though the Master data for these characteristics are shared, when I query just the characteristics to get an idea of the values recorded in my cube, I will not have problems. This is because within the Cube, the transaction data that comes in is created with correct context limited to the infoObject that it flows into. So when I take a material number and try and query Model Name, I will not encounter any results, because all the Material numbers arrive with the transaction data into the <b>0MATERIAL</b> InfoObject within the Cubes Transaction data. (And vice versa for using Material Numbers for Model name)

I am sure I could look at the SIDS and the DIMID's and trace this back starting at the fact table, but I am sure I won't be afforded the work time to do that!

Thanks again for your help!

Nick

Message was edited by: Nick Bertz