Showing posts with label attributes. Show all posts
Showing posts with label attributes. Show all posts

Sunday, March 25, 2012

Derived attributes in a dimension

SQL 2005 SSAS - is it possible to create a derived attribute in a Dimension or does it have to be done in the underlying table.

Specifically, I have a geographic location Dimension where the top level is "Area" (USGulf, USWestCoast, Caribbean etc). Now there is one part of the company that likes to group these together into Zones. I can see how to do this in SQL in the underlying table or in reports in SSRS, but ideally would like to do this in the cube.

Thanks

You could add a Named Calculation for Zone to the dimension table in the Data Source View. This would be a SQL expression - the underlying table structure wouldn't change.

Saturday, February 25, 2012

Deploy to production using Configuration Properties

Hi,

When you check out the project properties of a RS project, you can find the deployment attributes like targetdatasourcefolder, etc... There's also a button "Configuration Manager...". Here I can see a column "Platform" which is empty. I got the feeling I should be able to configure different platforms here, select an active environment and deploy to it some how. Is this correct; how does this work, and why not?

Regards, Jeroen

The Platform thing is not what you're looking for (it's like different CPU types). It doesn't really apply to what you want to do, it's for compilation purposes.

You deploy to different servers by creating different named configurations (Debug, Production, etc) and setting different target servers for those configurations.

In the Configuration Manager you "attach" one of those named configurations for your report project to one or more configuration setups for the solution as a whole and specifying whether the report project should be build and/or deployed as part of the build process for that solution configuration.

In the Configuration Manager, you also specify one configuration for the solution as "active" so that when you choose to build that is the set of instructions should be used.

When you choose to build and/or deploy specifically for a your report project, rather than for the full solution, I think that the server you have specified in the currently-active configuration settings in Configuration Manager still apply.

I hope that makes sense <g>.

>L<

Friday, February 17, 2012

dependency relations are different from different mining structures with same mining algorithms?

Hi, all here..

I got one problem in my data analysis case with SQL Server 2005 data mining algorithms-in the dependency network, the attributes mostly affected the predictive value are different in different mining structures tho.

For example, I got a, b,c as input attributes to predict attribute d, in mining structure 1 (with all attributes discretized), i got a as the attribute which has the strongest relation with predictive attribute d. However in mining structure 2 (with all attributes values continuous), I got attribute b as the strongest attribute with predictive attribute d?

So what is the problem tho? In this case, how can I tell which attribute actually has the strongest relation with predictive attribute?

Thanks a lot in advance for help.

This is expected. You are modeling two different problems here. In the discretized space you are asking "are ranges of data predictive of my target", in the other you are using the raw values.

For example, say you are predicting credit worthyness based on age and salary. If you discretize you are asking "which age and salary ranges indicate creditworthiness." Your ranges for age could be 0-10,11-20,21-40, etc. and salary could be 0-30k, 30-60k, etc.

In this model you may find that people who are in the 0-10 bucket have very little creditworthiness and therefore Age is the strongest predictor.

If you choose continuous, you may find that overall, a very low salary, e.g. < 13K was a stronger indicator and age overall played a minor role. This could be because the bucketing hid detail from the algorithm, or even (if predicting a continuous) because the salary played a stronger role in a regression formula.

|||Hi, Jamie,thanks a lot .