Regarding dimension renaming in AS2005 while migrtion

Hi,

My datamart has used dots in the dimension name. i.e. I have following dimensions

Users.Sales1 and Users.Sales2.

Currently my application has 2 cubes: Sales1 and Sales2.

Cube Sales1 is assocated with
"Parent Child" dimension Users.Sales1
which is based on view vw_Users_Sales1

Cube Sales2 is assocated with
"Parent Child" dimension Users.Sales2
which is based on view vw_Users_Sales2

Now when I am trying migration wizard, I am getting following dimensions

Users.Sales1 and Users1.Sales2.

Is there some way I can retain the existing naming convension?

And If not them what is the best convension or what will

will be the best possible to handle this scenario.

There are other dimensions as well which are getting renamed like this.

So I will like to know how others are handling this.

Thanks In Advance,

Rahul

The dimension model was changed in 2005. In 2000, you could have dimensions based off different tables that shared a common dimension name. The intention behind this was to support multiple hierarchies for the same dimension, but each one was still implemented as a seperate dimension, they just shared a common root name (Users, in your case).

2005 can now support multiple hierachies in the same dimension. However, they need to come from the same table or view. Since, in your case, they are comming from two different views, the wizard is creating two seperate dimensions. And you since you can't have two dimensions with the same name, the wizard is renaming one of them.

|||John is right, you might find that you are able to create a view or a named query as a quick way to join these tables together.

Reduce time connection to AS2005

what is "slow"?
when the pivottable access the cube, the first time a query is executed
against the server to retrieve the measure names, but this query also ask
for the data, not only the labels. (use the profiler to see this query)
if 1 of your measures is a complex one, then you'll suffer a delay.
if your metadata is more complex in your cubes, then the time required to
retrieve the metadata is longer.
verify if you have the right SP level installed on the server AND the client
verify if you have activated the compression
also, it could be an authencation issue, maybe you suffer a delay due to a
network configuration issue (verify the DNS configuration if you use the
Active Direcotry)
again, use the profiler on the server to identify the source of the problem.
"Kazmane" <mkazmane@.capinfo.co.ma> wrote in message
news:%23y9YKXulGHA.1972@.TK2MSFTNGP05.phx.gbl...
> can someone help to reduce a time connecting to As2005 with using OLEDB9.0
> and PivotTable.
> thanks.
>can someone help to reduce a time connecting to As2005 with using OLEDB9.0
and PivotTable.
thanks.|||what is "slow"?
when the pivottable access the cube, the first time a query is executed
against the server to retrieve the measure names, but this query also ask
for the data, not only the labels. (use the profiler to see this query)
if 1 of your measures is a complex one, then you'll suffer a delay.
if your metadata is more complex in your cubes, then the time required to
retrieve the metadata is longer.
verify if you have the right SP level installed on the server AND the client
verify if you have activated the compression
also, it could be an authencation issue, maybe you suffer a delay due to a
network configuration issue (verify the DNS configuration if you use the
Active Direcotry)
again, use the profiler on the server to identify the source of the problem.
"Kazmane" <mkazmane@.capinfo.co.ma> wrote in message
news:%23y9YKXulGHA.1972@.TK2MSFTNGP05.phx.gbl...
> can someone help to reduce a time connecting to As2005 with using OLEDB9.0
> and PivotTable.
> thanks.
>

Reduce Records Shown From Dimension

Hi There,

I'm relatively new to AS2005, so you'll have to excuse me if there is a simple solution that has been overlooked.

Here is the situation - We have a fact table, linked to several dimensions - one of them being a generic date dimension used by a number of fact tables. The Date Dimension has all dates ranging from 1901 to 2100, but the fact table I am querying just has records from 2005 to present. Once the cube is processed and I open the cube in Excel (for example) it lists every date from the Date Dimension, is there any way to limit which dates are processed into the cube to those that just appear in the fact table (in essence - what would be an Inner Join in TSQL).

Hope this makes sense,

Regards,

Tobias

Are you using the dimension on rows or columns? Or as a filter?

If it is rows or columns you change the setting to not show empty values.

If it is a filter, you could create a set that only contains only those dates that has rows. Regardless, you could probably remove a lot of dates from the time dimension that is not used by any fact table and/or create a view that adds dates as time goes by.|||

Instead of telling the cube (via the data source view) to read directly from the time dimension table, we tend to use db views that restrict the members to only those members that appear in the fact table. You can change the dsv to read from the view and you will then only get dates that appear in the fact table.

However, with the time dimension, you want to make sure you fill in all dates of a year -- if you don't you can't really do year-over-year comparisons reliably. So, perhaps you can have the view return all dates from your time dimension table that start AFTER the first date in your fact table. You can use similar logic to restrict the dates on the high end as well.

|||

So does this mean, for each fact table - you have a different view set up?

We have about 15-20 cubes that we want to set up which all use the time dimension, with varying volumes of historical data from each of the source systems. Is it best practise to then limit the data returned by the dimension for each group of cubes?

I was hoping that there would be a technique/feature that prevented 'redundant' (i.e. rows that do not have a related fact record) dimension members from appearing in the cube, that way we could begin to build the suite of cubes in a smaller number of projects and reduce administrative overheads (by having several Time Dim views for different date ranges for example)

Regards,

Tobias

|||

Well, our one view looks at all of our various fact tables to determine which entries are needed.

The problem you have is that Excel will list out all dimension members, so I'm not sure what the best solution is for you. But I don't think there is magic property that you can tell Excel to list only dimension members that are only for a particular cube.

|||Is it Excel 2007 you use? Because then you can create a named set that only contains dates that are non empty, has rows in the fact table connected to it. I′m not sure if Excel 2003 can use sets.|||We're using Excel 2003. shame there isn't a feature that does that.|||

Even in Excel 2003 pivot table, you have the option to hide the members that do not have data.

As you are using time dimension in different measure groups, the best practice would be to create hierarchy in the date dimension like Year ==> Month ==> Date levels that would make the navigation easier for the users. There are lot of articles on ways to handle it. Pl refer to BOL and newsgroups.