Cube Metadata: FM Package vs Content Datasource

[Northern_Monkey]

Does anyone have experience with using FM packages as data sources as a data source for cubes?
Seem fairly limited to me, you can import a query item as a dimension/measure dimension and that's it.

Am I right in thinking you can't add a 'Query Item' individually to a 'New Attribute'?
Also, in order to specify levels in the model you would have to have DMR set up in the package?
I thought of publishing the FM package and trying to create levels in the Cube Designer but it seems I can't.

The problem I find with using the Content Datasource is that you cant create a Cube Dimension from multiple tables.

Does anyone have any experience or thoughts on this?

Thanks

[bus_pass_man]

Does anyone have experience with using FM packages as data sources as a data source for cubes?

A wee bit.

It isn't a data source, it's a metadata source but I know what you mean.

Seem fairly limited to me, you can import a query item as a dimension/measure dimension and that's it.

Actually, you can import a measure dimension and it will create cubes based on the measure dimension and all the dimensions which have scope relationships to the measure dimension.  You can import dimensions.  Other stuff too.  There's a table listing what you can do in the Dynamic Cube Redbook.  Have you had a chance to go through the chapter on FM migration?

The primary case for importing FM packages is where you have tried DMR and it has not scaled well enough and you want to use dynamic cubes.  Importing the FM package allows you to salvage much of your modeling effort.

Also, in order to specify levels in the model you would have to have DMR set up in the package?
I thought of publishing the FM package and trying to create levels in the Cube Designer but it seems I can't.

Using query subjects I presume. Dimensions should get replicated with a high level of fidelity. Without any metadata assistance trying to create hierarchies from a query subject would be difficult.  Can you explain what difficulty you are encountering in more detail please. 

The problem I find with using the Content Datasource is that you cant create a Cube Dimension from multiple tables.

Not sure what you mean by 'cube dimension' but you can create a dimension from multiple tables.  Can you explain what difficulty you are encountering in more detail please.  Are you trying to create the dimension from multiple tables while you trying the import?


Hope that helps.

[Northern_Monkey]

Thanks for coming back to me.

My apologies, I should know to be clearer with my terminology!

Yes I meant metadata source!

I was really looking at the pros and cons of modelling the cube objects in FM. This was really based around levering existing joins in the package and to try and keep all modelling objects in one place. In isolation it seems like a bad idea but for a large scale BI implementation, it may prove easier to manage and provide some guidelines and tighter controls for developers.

Some of the modelling challenges have evolved from just the ETL layer/DB layer in to the Framework and I wanted to try and utilise the work already done with the 'Star Schema' outputs that are published as packages.

I tried creating a new cube using a FM metadata source. The namespace in FM contained Query Subjects (Dims + Fact). Very simple star schema example. In Cube Designer trying to import the namespace fails as it cant find 'dimensions' and 'facts'. So I end up importing the individual query items as either a 'As a dimension' or 'As the measure dimension of a new cube'.
Unfortunately I find this useless to me as the native joins that existed in the FM package are no longer available in Cube Designer. Also, when I try to edit the 'relationships' in the editor, none of the query items from the query subject are available. Let's say the issue with the 'relationships' is a bug and I can create the relationships between my dimension and measures.... There is no way to create levels in the hierarchy using the query items from the query subject that originate in my FM package. You cannot use the query items from the published package, only query subjects!?
So, next....

I tried creating a DMR. Simple example. 1 dimension with 2 levels. 1 measure dimension. Scope set and all correct in FM.
When I use the DMR as a source for a cube. (Right click on the namespace - Import As Cubes). The relationships are lost. I though the relationship should remain?


As you suggested i'll go back over the FM migration section of the redbook.

Lastly, when creating a dimension using metadata from the 'Content Manager Datasource', I'm not able to use more than one table because there is no way to specify joins between the tables. For example, if you created a merged query subject in FM, then it would come from multiple tables. Its seems this cant be done in Cube Designer. The relationships have to exist in the database already?

[bus_pass_man]

OK,  let's start by looking at the problem you encountered with your dmr. 

In each dimension's implementation diagram you should see all of the query subjects (tables) used in the data base (query) layer of your FM model.  They ought to have their relationships mapped to analogues in the dimension but that doesn't always happen.  You should be able to see all the query items (columns) of those tables.  If you can't, try setting the level of detail scroll bar to display every thing.  In the case where a relationship was not successfully mapped, you would need to re-create it in the implementation diagram.  I think what might be contributing to your confusion is that you're looking for the business layer model query subject, which isn't there. 

I think that could answer the last point you had.  The relationships do not need to already exist in the database.  You create relationships between stuff in the dimension in the implementation diagram. 

The next thing is that you're getting hung up with the UI, which is the type you get from the minds of Socialists.

The only thing you are meant to do with the imported FM package is choose what things you want to bring into Cube Designer.  Anything else is done with the metadata from the data sources and by modeling the dimensions and cubes.  I don't know why it was decided to clutter up the works by supporting anything other than the migration of DMR objects to their analogue dynamic cube objects.  You will notice that if you had hidden objects in the package they are exposed so you end up wondering what you need to do with them as well.

For example if you import a query subject as a dimension you end up with a single level dimension with all the query items as its attributes.  Any further refinements need to be done through editing the dimension.

Wrapping your brain around the Cube Designer paradigm and comparing it to the DMR paradigm is a tough thing, especially if you are just getting your toe into the dynamic cube water.

[Northern_Monkey]

Many Thanks

[bus_pass_man]

de rien