Cons for each Cube having private time dimension

Cons for each Cube having private time dimension

Post by Gary Billin » Thu, 01 Aug 2002 21:12:28



Folks,

I was contemplating creating private time dimensions for  
each cube. Each private time dimension would have a
property at the year level for the current period.
This property would be used as a default for the private
time dimension.

The posting of the cubes are independently scheduled and
the current period of each private time dimension would be
updated after the data had been refreshed in that cube.

Would private time dimensions create any restrictions?
Can data be shared between cubes even though private time
dimensions are used?

Thanks
Gary

 
 
 

Cons for each Cube having private time dimension

Post by George Spoffor » Thu, 01 Aug 2002 22:03:41


If at any one point in time each cube may have a different "current
period" due to the scheduling of updates, then perhaps having private
time dimensions is the way to go. You'll need to do a little
hoop-jumping to combine them into a virtual cube if you wanted to,
though, as you'll have N different time dimensions. You can use the
LookupCube() function to merge data from them, however.

How is the property used? At each year, what will the value of the
property contain? If there are 3 years, will they each contain the same
value or 3?


> Folks,

> I was contemplating creating private time dimensions for
> each cube. Each private time dimension would have a
> property at the year level for the current period.
> This property would be used as a default for the private
> time dimension.

> The posting of the cubes are independently scheduled and
> the current period of each private time dimension would be
> updated after the data had been refreshed in that cube.

> Would private time dimensions create any restrictions?
> Can data be shared between cubes even though private time
> dimensions are used?

> Thanks
> Gary

--
George Spofford
Microsoft MVP
Chief Architect / OLAP Solution Provider
DSS Lab
http://www.dsslab.com

ISVs & IT organizations: Find out how DSS Lab can speed your
development!

 
 
 

Cons for each Cube having private time dimension

Post by Gary Billin » Thu, 01 Aug 2002 22:33:17


How is the property used?
I was thinking of used function Ancestor
([Time].currentMember,
[Fiscal Yr]).properties("currentWeekEnding")

At each year, what will the value of the property contain?
It would contain the last week of the year?

If there are 3 years, will they each contain the same
value or 3?
They would contain 3 different values since
currentWeekEnding data values includes a year signature.

Instead of Private dimensions, how about using different
virtual time dimensions per cube. Each virtual time
dimension could retrieve the currentWeekEnding data value
from different columns in the dimTime table. Would this
overcome the hoops when doing data sharing? How should I
name the different currentWeekEnding columns in the
dimTime table?

Thanks
Gary

>-----Original Message-----
>If at any one point in time each cube may have a
different "current
>period" due to the scheduling of updates, then perhaps
having private
>time dimensions is the way to go. You'll need to do a
little
>hoop-jumping to combine them into a virtual cube if you
wanted to,
>though, as you'll have N different time dimensions. You
can use the
>LookupCube() function to merge data from them, however.

>How is the property used? At each year, what will the
value of the
>property contain? If there are 3 years, will they each
contain the same
>value or 3?


>> Folks,

>> I was contemplating creating private time dimensions for
>> each cube. Each private time dimension would have a
>> property at the year level for the current period.
>> This property would be used as a default for the private
>> time dimension.

>> The posting of the cubes are independently scheduled and
>> the current period of each private time dimension would
be
>> updated after the data had been refreshed in that cube.

>> Would private time dimensions create any restrictions?
>> Can data be shared between cubes even though private
time
>> dimensions are used?

>> Thanks
>> Gary

>--
>George Spofford
>Microsoft MVP
>Chief Architect / OLAP Solution Provider
>DSS Lab
>http://www.dsslab.com

>ISVs & IT organizations: Find out how DSS Lab can speed
your
>development!

>.

 
 
 

Cons for each Cube having private time dimension

Post by George Spoffor » Fri, 02 Aug 2002 00:40:18


Or just one shared time dimension with 1 property per cube. This ought
to be the easiest.


> How is the property used?
> I was thinking of used function Ancestor
> ([Time].currentMember,
> [Fiscal Yr]).properties("currentWeekEnding")

> At each year, what will the value of the property contain?
> It would contain the last week of the year?

> If there are 3 years, will they each contain the same
> value or 3?
> They would contain 3 different values since
> currentWeekEnding data values includes a year signature.

> Instead of Private dimensions, how about using different
> virtual time dimensions per cube. Each virtual time
> dimension could retrieve the currentWeekEnding data value
> from different columns in the dimTime table. Would this
> overcome the hoops when doing data sharing? How should I
> name the different currentWeekEnding columns in the
> dimTime table?

> Thanks
> Gary
> >-----Original Message-----
> >If at any one point in time each cube may have a
> different "current
> >period" due to the scheduling of updates, then perhaps
> having private
> >time dimensions is the way to go. You'll need to do a
> little
> >hoop-jumping to combine them into a virtual cube if you
> wanted to,
> >though, as you'll have N different time dimensions. You
> can use the
> >LookupCube() function to merge data from them, however.

> >How is the property used? At each year, what will the
> value of the
> >property contain? If there are 3 years, will they each
> contain the same
> >value or 3?


> >> Folks,

> >> I was contemplating creating private time dimensions for
> >> each cube. Each private time dimension would have a
> >> property at the year level for the current period.
> >> This property would be used as a default for the private
> >> time dimension.

> >> The posting of the cubes are independently scheduled and
> >> the current period of each private time dimension would
> be
> >> updated after the data had been refreshed in that cube.

> >> Would private time dimensions create any restrictions?
> >> Can data be shared between cubes even though private
> time
> >> dimensions are used?

> >> Thanks
> >> Gary

> >--
> >George Spofford
> >Microsoft MVP
> >Chief Architect / OLAP Solution Provider
> >DSS Lab
> >http://www.dsslab.com

> >ISVs & IT organizations: Find out how DSS Lab can speed
> your
> >development!

> >.

--
George Spofford
Microsoft MVP
Chief Architect / OLAP Solution Provider
DSS Lab
http://www.dsslab.com

ISVs & IT organizations: Find out how DSS Lab can speed your
development!
 
 
 

Cons for each Cube having private time dimension

Post by Gary Billin » Fri, 02 Aug 2002 01:00:31


I don't understand how to use one shared time dimension.
I was planning to set the default member property on the
advanced tab of the shared dimension editor. The default
member property is not available while editing the
included dimension within a cube. Is there another way?

I misspoke earlier. It appears that I can only have the
default at the ALL level rather than at the year level.
The default member definition would be the only thing
different in the virtual time dimensions
Ancestor([Time].currentMember,
[All Time]).properties("process1WeekEnding")
where process1 is the cube #1 refresh
      ...
      processn is the Cube #N refresh

Thanks
Gary

>-----Original Message-----
>Or just one shared time dimension with 1 property per
cube. This ought
>to be the easiest.


>> How is the property used?
>> I was thinking of used function Ancestor
>> ([Time].currentMember,
>> [Fiscal Yr]).properties("currentWeekEnding")

>> At each year, what will the value of the property
contain?
>> It would contain the last week of the year?

>> If there are 3 years, will they each contain the same
>> value or 3?
>> They would contain 3 different values since
>> currentWeekEnding data values includes a year signature.

>> Instead of Private dimensions, how about using different
>> virtual time dimensions per cube. Each virtual time
>> dimension could retrieve the currentWeekEnding data
value
>> from different columns in the dimTime table. Would this
>> overcome the hoops when doing data sharing? How should I
>> name the different currentWeekEnding columns in the
>> dimTime table?

>> Thanks
>> Gary
>> >-----Original Message-----
>> >If at any one point in time each cube may have a
>> different "current
>> >period" due to the scheduling of updates, then perhaps
>> having private
>> >time dimensions is the way to go. You'll need to do a
>> little
>> >hoop-jumping to combine them into a virtual cube if you
>> wanted to,
>> >though, as you'll have N different time dimensions. You
>> can use the
>> >LookupCube() function to merge data from them, however.

>> >How is the property used? At each year, what will the
>> value of the
>> >property contain? If there are 3 years, will they each
>> contain the same
>> >value or 3?


>> >> Folks,

>> >> I was contemplating creating private time dimensions
for
>> >> each cube. Each private time dimension would have a
>> >> property at the year level for the current period.
>> >> This property would be used as a default for the
private
>> >> time dimension.

>> >> The posting of the cubes are independently scheduled
and
>> >> the current period of each private time dimension
would
>> be
>> >> updated after the data had been refreshed in that
cube.

>> >> Would private time dimensions create any
restrictions?
>> >> Can data be shared between cubes even though private
>> time
>> >> dimensions are used?

>> >> Thanks
>> >> Gary

>> >--
>> >George Spofford
>> >Microsoft MVP
>> >Chief Architect / OLAP Solution Provider
>> >DSS Lab
>> >http://www.dsslab.com

>> >ISVs & IT organizations: Find out how DSS Lab can speed
>> your
>> >development!

>> >.

>--
>George Spofford
>Microsoft MVP
>Chief Architect / OLAP Solution Provider
>DSS Lab
>http://www.dsslab.com

>ISVs & IT organizations: Find out how DSS Lab can speed
your
>development!

>.

 
 
 

Cons for each Cube having private time dimension

Post by George Spoffor » Fri, 02 Aug 2002 01:34:26


Well, if there was > 1 value for the member property, its values weren't
going to be useful as default members without some extra thought..

Are you saying that you wanted the default member to be defined by the
formula

Ancestor([Time].currentMember,
[All Time]).properties("process1WeekEnding")?

This might not have worked anyway. At the time the expression is
evaluated, the current member of Time is [Time].[All Time] anyway, and
you unless you define the All level yourself in the time table, it can't
have any member properties.

With private dimensions, each can have a property with the same-name,
which will get around the problem. You could have 1 property named
ProcessWeekEnding and an expression like

StrToMember (
  "[Time].["
  + Tail (
    [Time].[Year].Members,
    1).Item(0).Item(0).Properties ("ProcessWeekEnding")
  + "]"
)

to get the property from the most recent year. To use a shared time
dimension, you can define a hidden calculated measure called [Cube Name]
in each cube that returns the name of the cube, and then use the formula

StrToMember (
  "[Time].["
  + Tail (
    [Time].[Year].Members,
    1).Item(0).Item(0).Properties ("Process" + CStr([Measures].[Cube
Name]) + WeekEnding")
  + "]"
)

where in cube ABC, it references property "ProcessABCWeekEnding", in
cube XYZ it references property "ProcessXYAWeekEnding", etc. Just make
sure that when you take the value of the member property and wrap
[Time].[...] around it, you get a valid member name.

HTH


> I don't understand how to use one shared time dimension.
> I was planning to set the default member property on the
> advanced tab of the shared dimension editor. The default
> member property is not available while editing the
> included dimension within a cube. Is there another way?

> I misspoke earlier. It appears that I can only have the
> default at the ALL level rather than at the year level.
> The default member definition would be the only thing
> different in the virtual time dimensions
> Ancestor([Time].currentMember,
> [All Time]).properties("process1WeekEnding")
> where process1 is the cube #1 refresh
>       ...
>       processn is the Cube #N refresh

> Thanks
> Gary

> >-----Original Message-----
> >Or just one shared time dimension with 1 property per
> cube. This ought
> >to be the easiest.


> >> How is the property used?
> >> I was thinking of used function Ancestor
> >> ([Time].currentMember,
> >> [Fiscal Yr]).properties("currentWeekEnding")

> >> At each year, what will the value of the property
> contain?
> >> It would contain the last week of the year?

> >> If there are 3 years, will they each contain the same
> >> value or 3?
> >> They would contain 3 different values since
> >> currentWeekEnding data values includes a year signature.

> >> Instead of Private dimensions, how about using different
> >> virtual time dimensions per cube. Each virtual time
> >> dimension could retrieve the currentWeekEnding data
> value
> >> from different columns in the dimTime table. Would this
> >> overcome the hoops when doing data sharing? How should I
> >> name the different currentWeekEnding columns in the
> >> dimTime table?

> >> Thanks
> >> Gary
> >> >-----Original Message-----
> >> >If at any one point in time each cube may have a
> >> different "current
> >> >period" due to the scheduling of updates, then perhaps
> >> having private
> >> >time dimensions is the way to go. You'll need to do a
> >> little
> >> >hoop-jumping to combine them into a virtual cube if you
> >> wanted to,
> >> >though, as you'll have N different time dimensions. You
> >> can use the
> >> >LookupCube() function to merge data from them, however.

> >> >How is the property used? At each year, what will the
> >> value of the
> >> >property contain? If there are 3 years, will they each
> >> contain the same
> >> >value or 3?


> >> >> Folks,

> >> >> I was contemplating creating private time dimensions
> for
> >> >> each cube. Each private time dimension would have a
> >> >> property at the year level for the current period.
> >> >> This property would be used as a default for the
> private
> >> >> time dimension.

> >> >> The posting of the cubes are independently scheduled
> and
> >> >> the current period of each private time dimension
> would
> >> be
> >> >> updated after the data had been refreshed in that
> cube.

> >> >> Would private time dimensions create any
> restrictions?
> >> >> Can data be shared between cubes even though private
> >> time
> >> >> dimensions are used?

> >> >> Thanks
> >> >> Gary

> >> >--
> >> >George Spofford
> >> >Microsoft MVP
> >> >Chief Architect / OLAP Solution Provider
> >> >DSS Lab
> >> >http://www.dsslab.com

> >> >ISVs & IT organizations: Find out how DSS Lab can speed
> >> your
> >> >development!

> >> >.

> >--
> >George Spofford
> >Microsoft MVP
> >Chief Architect / OLAP Solution Provider
> >DSS Lab
> >http://www.dsslab.com

> >ISVs & IT organizations: Find out how DSS Lab can speed
> your
> >development!

> >.

--
George Spofford
Microsoft MVP
Chief Architect / OLAP Solution Provider
DSS Lab
http://www.dsslab.com

ISVs & IT organizations: Find out how DSS Lab can speed your
development!
 
 
 

Cons for each Cube having private time dimension

Post by Gary Billin » Fri, 02 Aug 2002 03:27:26


I chose this formula based on a presentation by
Hilary Feier called Dealing with time in a
MultiDimensional space:
StrtoMember ("[" +
Ancestor([time].currentmember,[Year Name]}.properties
("Currentmember Date") + "]")

Using your formula

Quote:

>StrToMember (
>  "[Time].["
>  + Tail (
>    [Time].[Year].Members,
>    1).Item(0).Item(0).Properties ("Process" + CStr
([Measures].[Cube
>Name]) + WeekEnding")
>  + "]"
>)

Does this mean that the last time dimension member for the
last year is used? The last year in my dimension table is
2003. I do not understand syntax .item(0).Item(0)!

Thanks
Gary

Quote:>-----Original Message-----
>Well, if there was > 1 value for the member property, its
values weren't
>going to be useful as default members without some extra
thought..

>Are you saying that you wanted the default member to be
defined by the
>formula

>Ancestor([Time].currentMember,
>[All Time]).properties("process1WeekEnding")?

>This might not have worked anyway. At the time the
expression is
>evaluated, the current member of Time is [Time].[All
Time] anyway, and
>you unless you define the All level yourself in the time
table, it can't
>have any member properties.

>With private dimensions, each can have a property with
the same-name,
>which will get around the problem. You could have 1
property named
>ProcessWeekEnding and an expression like

>StrToMember (
>  "[Time].["
>  + Tail (
>    [Time].[Year].Members,
>    1).Item(0).Item(0).Properties ("ProcessWeekEnding")
>  + "]"
>)

>to get the property from the most recent year. To use a
shared time
>dimension, you can define a hidden calculated measure
called [Cube Name]
>in each cube that returns the name of the cube, and then
use the formula

>StrToMember (
>  "[Time].["
>  + Tail (
>    [Time].[Year].Members,
>    1).Item(0).Item(0).Properties ("Process" + CStr
([Measures].[Cube
>Name]) + WeekEnding")
>  + "]"
>)

>where in cube ABC, it references

property "ProcessABCWeekEnding", in

- Show quoted text -

>cube XYZ it references property "ProcessXYAWeekEnding",
etc. Just make
>sure that when you take the value of the member property
and wrap
>[Time].[...] around it, you get a valid member name.

>HTH


>> I don't understand how to use one shared time dimension.
>> I was planning to set the default member property on the
>> advanced tab of the shared dimension editor. The default
>> member property is not available while editing the
>> included dimension within a cube. Is there another way?

>> I misspoke earlier. It appears that I can only have the
>> default at the ALL level rather than at the year level.
>> The default member definition would be the only thing
>> different in the virtual time dimensions
>> Ancestor([Time].currentMember,
>> [All Time]).properties("process1WeekEnding")
>> where process1 is the cube #1 refresh
>>       ...
>>       processn is the Cube #N refresh

>> Thanks
>> Gary

>> >-----Original Message-----
>> >Or just one shared time dimension with 1 property per
>> cube. This ought
>> >to be the easiest.


>> >> How is the property used?
>> >> I was thinking of used function Ancestor
>> >> ([Time].currentMember,
>> >> [Fiscal Yr]).properties("currentWeekEnding")

>> >> At each year, what will the value of the property
>> contain?
>> >> It would contain the last week of the year?

>> >> If there are 3 years, will they each contain the same
>> >> value or 3?
>> >> They would contain 3 different values since
>> >> currentWeekEnding data values includes a year
signature.

>> >> Instead of Private dimensions, how about using
different
>> >> virtual time dimensions per cube. Each virtual time
>> >> dimension could retrieve the currentWeekEnding data
>> value
>> >> from different columns in the dimTime table. Would
this
>> >> overcome the hoops when doing data sharing? How
should I
>> >> name the differen{ wH:H | # ?o""?Y  ?      t

currentWeekEnding columns in the

- Show quoted text -

>> >> dimTime table?

>> >> Thanks
>> >> Gary
>> >> >-----Original Message-----
>> >> >If at any one point in time each cube may have a
>> >> different "current
>> >> >period" due to the scheduling of updates, then
perhaps
>> >> having private
>> >> >time dimensions is the way to go. You'll need to do
a
>> >> little
>> >> >hoop-jumping to combine them into a virtual cube if
you
>> >> wanted to,
>> >> >though, as you'll have N different time dimensions.
You
>> >> can use the
>> >> >LookupCube() function to merge data from them,
however.

>> >> >How is the property used? At each year, what will
the
>> >> value of the
>> >> >property contain? If there are 3 years, will they
each
>> >> contain the same
>> >> >value or 3?


>> >> >> Folks,

>> >> >> I was contemplating creating private time
dimensions
>> for
>> >> >> each cube. Each private time dimension would have
a
>> >> >> property at the year level for the current period.
>> >> >> This property would be used as a default for the
>> private
>> >> >> time dimension.

>> >> >> The posting of the cubes are independently
scheduled
>> and
>> >> >> the current period of each private time dimension
>> would
>> >> be
>> >> >> updated after the data had been refreshed in that
>> cube.

>> >> >> Would private time dimensions create any
>> restrictions?
>> >> >> Can data be shared between cubes even though
private
>> >> time
>> >> >> dimensions are used?

>> >> >> Thanks
>> >> >> Gary

>> >> >--
>> >> >George Spofford
>> >> >Microsoft MVP
>> >> >Chief Architect / OLAP Solution Provider
>> >> >DSS Lab
>> >> >http://www.dsslab.com

>> >> >ISVs & IT organizations: Find out how DSS Lab can
speed
>> >> your
>> >> >development!

>> >> >.

>> >--
>> >George Spofford
>> >Microsoft MVP
>> >Chief Architect / OLAP Solution Provider
>> >DSS Lab
>> >http://www.dsslab.com

>> >ISVs & IT organizations: Find out how DSS Lab can speed
>> your
>> >development!

>> >.

>--
>George Spofford
>Microsoft MVP
>Chief Architect / OLAP Solution Provider
>DSS Lab
>http://www.dsslab.com

>ISVs & IT organizations: Find out how DSS Lab can speed
your
>development!

>.

 
 
 

Cons for each Cube having private time dimension

Post by George Spoffor » Fri, 02 Aug 2002 04:30:54


That formula will only work best if the value of "Currentmember Date"
looks like "Time].[July 31, 2002", otherwise, it could be a little slow
because AS2K may need to search each dimension to find the member. I
imagine her discussion included other details- this looks pretty
representational. In my suggestion, it only needs to look like "July 31,
2002". I think it must have been intended for another context as well- I
can't imagine her suggesting this for use as a default member formula.
Consider what I said earlier about the "current member" when the default
is evaluated, as well as the lack of member properties at the [(All)]
level. Her formula gets you the current date of the year the current
member happens to be under, which is not what you are looking for.

Can you identify the processed period of the cube by the last period
that has data for some sentinel measure? If so, you could use:

Filter (
  [Time].[Day].Members,
  Not IsEmpty ([Measures].[<some measure here>])
).Item(0).Item(0)

as the expression in each cube.

Look at the BOL for .Item().

HTH

Gary Billins wrote:
> I chose this formula based on a presentation by
> Hilary Feier called Dealing with time in a
> MultiDimensional space:
> StrtoMember ("[" +
> Ancestor([time].currentmember,[Year Name]}.properties
> ("Currentmember Date") + "]")

> Using your formula

> >StrToMember (
> >  "[Time].["
> >  + Tail (
> >    [Time].[Year].Members,
> >    1).Item(0).Item(0).Properties ("Process" + CStr
> ([Measures].[Cube
> >Name]) + WeekEnding")
> >  + "]"
> >)

> Does this mean that the last time dimension member for the
> last year is used? The last year in my dimension table is
> 2003. I do not understand syntax .item(0).Item(0)!

> Thanks
> Gary
> >-----Original Message-----
> >Well, if there was > 1 value for the member property, its
> values weren't
> >going to be useful as default members without some extra
> thought..

> >Are you saying that you wanted the default member to be
> defined by the
> >formula

> >Ancestor([Time].currentMember,
> >[All Time]).properties("process1WeekEnding")?

> >This might not have worked anyway. At the time the
> expression is
> >evaluated, the current member of Time is [Time].[All
> Time] anyway, and
> >you unless you define the All level yourself in the time
> table, it can't
> >have any member properties.

> >With private dimensions, each can have a property with
> the same-name,
> >which will get around the problem. You could have 1
> property named
> >ProcessWeekEnding and an expression like

> >StrToMember (
> >  "[Time].["
> >  + Tail (
> >    [Time].[Year].Members,
> >    1).Item(0).Item(0).Properties ("ProcessWeekEnding")
> >  + "]"
> >)

> >to get the property from the most recent year. To use a
> shared time
> >dimension, you can define a hidden calculated measure
> called [Cube Name]
> >in each cube that returns the name of the cube, and then
> use the formula

> >StrToMember (
> >  "[Time].["
> >  + Tail (
> >    [Time].[Year].Members,
> >    1).Item(0).Item(0).Properties ("Process" + CStr
> ([Measures].[Cube
> >Name]) + WeekEnding")
> >  + "]"
> >)

> >where in cube ABC, it references
> property "ProcessABCWeekEnding", in
> >cube XYZ it references property "ProcessXYAWeekEnding",
> etc. Just make
> >sure that when you take the value of the member property
> and wrap
> >[Time].[...] around it, you get a valid member name.

> >HTH

> >Gary Billins wrote:

> >> I don't understand how to use one shared time dimension.
> >> I was planning to set the default member property on the
> >> advanced tab of the shared dimension editor. The default
> >> member property is not available while editing the
> >> included dimension within a cube. Is there another way?

> >> I misspoke earlier. It appears that I can only have the
> >> default at the ALL level rather than at the year level.
> >> The default member definition would be the only thing
> >> different in the virtual time dimensions
> >> Ancestor([Time].currentMember,
> >> [All Time]).properties("process1WeekEnding")
> >> where process1 is the cube #1 refresh
> >>       ...
> >>       processn is the Cube #N refresh

> >> Thanks
> >> Gary

> >> >-----Original Message-----
> >> >Or just one shared time dimension with 1 property per
> >> cube. This ought
> >> >to be the easiest.

> >> >Gary Billins wrote:

> >> >> How is the property used?
> >> >> I was thinking of used function Ancestor
> >> >> ([Time].currentMember,
> >> >> [Fiscal Yr]).properties("currentWeekEnding")

> >> >> At each year, what will the value of the property
> >> contain?
> >> >> It would contain the last week of the year?

> >> >> If there are 3 years, will they each contain the same
> >> >> value or 3?
> >> >> They would contain 3 different values since
> >> >> currentWeekEnding data values includes a year
> signature.

> >> >> Instead of Private dimensions, how about using
> different
> >> >> virtual time dimensions per cube. Each virtual time
> >> >> dimension could retrieve the currentWeekEnding data
> >> value
> >> >> from different columns in the dimTime table. Would
> this
> >> >> overcome the hoops when doing data sharing? How
> should I
> >> >> name the differen{ wH:H | # ?o""?Y  ?  t
> currentWeekEnding columns in the
> >> >> dimTime table?

> >> >> Thanks
> >> >> Gary
> >> >> >-----Original Message-----
> >> >> >If at any one point in time each cube may have a
> >> >> different "current
> >> >> >period" due to the scheduling of updates, then
> perhaps
> >> >> having private
> >> >> >time dimensions is the way to go. You'll need to do
> a
> >> >> little
> >> >> >hoop-jumping to combine them into a virtual cube if
> you
> >> >> wanted to,
> >> >> >though, as you'll have N different time dimensions.
> You
> >> >> can use the
> >> >> >LookupCube() function to merge data from them,
> however.

> >> >> >How is the property used? At each year, what will
> the
> >> >> value of the
> >> >> >property contain? If there are 3 years, will they
> each
> >> >> contain the same
> >> >> >value or 3?

> >> >> >Gary Billins wrote:

> >> >> >> Folks,

> >> >> >> I was contemplating creating private time
> dimensions
> >> for
> >> >> >> each cube. Each private time dimension would have
> a
> >> >> >> property at the year level for the current period.
> >> >> >> This property would be used as a default for the
> >> private
> >> >> >> time dimension.

> >> >> >> The posting of the cubes are independently
> scheduled
> >> and
> >> >> >> the current period of each private time dimension
> >> would
> >> >> be
> >> >> >> updated after the data had been refreshed in that
> >> cube.

> >> >> >> Would private time dimensions create any
> >> restrictions?
> >> >> >> Can data be shared between cubes even though
> private
> >> >> time
> >> >> >> dimensions are used?

> >> >> >> Thanks
> >> >> >> Gary

> >> >> >--
> >> >> >George Spofford
> >> >> >Microsoft MVP
> >> >> >Chief Architect / OLAP Solution Provider
> >> >> >DSS Lab
> >> >> >http://www.dsslab.com
> >> >> >geo...@dsslab.com
> >> >> >ISVs & IT organizations: Find out how DSS Lab can
> speed
> >> >> your
> >> >> >development!

> >> >> >.

> >> >--
> >> >George Spofford
> >> >Microsoft MVP
> >> >Chief Architect / OLAP Solution Provider
> >> >DSS Lab
> >> >http://www.dsslab.com
> >> >geo...@dsslab.com
> >> >ISVs & IT organizations: Find out how DSS Lab can speed
> >> your
> >> >development!

> >> >.

> >--
> >George Spofford
> >Microsoft MVP
> >Chief Architect / OLAP Solution Provider
> >DSS Lab
> >http://www.dsslab.com
> >geo...@dsslab.com
> >ISVs & IT organizations: Find out how DSS Lab can speed
> your
> >development!

> >.

--
George Spofford
Microsoft MVP
Chief Architect / OLAP Solution Provider
DSS Lab
http://www.dsslab.com
geo...@dsslab.com
ISVs & IT organizations: Find out how DSS Lab can speed your
development!
 
 
 

Cons for each Cube having private time dimension

Post by Gary Billin » Fri, 02 Aug 2002 22:19:10


The simplicity of this approach using formula
Filter (
  [Time].[Day].Members,
  Not IsEmpty ([Measures].[<some measure here>])
).Item(0).Item(0)
is very tempting.
I presume that since a new period in its entirety is
loaded to the cube each time the cube is refreshed then I
think the client would get the new default period before
all the new period data has been loaded ... but I guess
will can live with this situation.
.. but to get the value of weekending for the latest
posting with a non empty measure shouldn't the formula be
like

  Tail(
  Filter (
  [Time].[WeekEnding].Members,
  Not IsEmpty ([Measures].[<some measure here>])
  )
  )

Thanks
Gary

Quote:>-----Original Message-----
>That formula will only work best if the value

of "Currentmember Date"
>looks like "Time].[July 31, 2002", otherwise, it could be
a little slow
>because AS2K may need to search each dimension to find
the member. I
>imagine her discussion included other details- this looks
pretty
>representational. In my suggestion, it only needs to look
like "July 31,
>2002". I think it must have been intended for another
context as well- I
>can't imagine her suggesting this for use as a default
member formula.
>Consider what I said earlier about the "current member"
when the default
>is evaluated, as well as the lack of member properties at
the [(All)]
>level. Her formula gets you the current date of the year
the current
>member happens to be under, which is not what you are
looking for.

>Can you identify the processed period of the cube by the
last period
>that has data for some sentinel measure? If so, you could
use:

>Filter (
>  [Time].[Day].Members,
>  Not IsEmpty ([Measures].[<some measure here>])
>).Item(0).Item(0)

>as the expression in each cube.

>Look at the BOL for .Item().

>HTH


>> I chose this formula based on a presentation by
>> Hilary Feier called Dealing with time in a
>> MultiDimensional space:
>> StrtoMember ("[" +
>> Ancestor([time].currentmember,[Year Name]}.properties
>> ("Currentmember Date") + "]")

>> Using your formula

>> >StrToMember (
>> >  "[Time].["
>> >  + Tail (
>> >    [Time].[Year].Members,
>> >    1).Item(0).Item(0).Properties ("Process" + CStr
>> ([Measures].[Cube
>> >Name]) + WeekEnding")
>> >  + "]"
>> >)

>> Does this mean that the last time dimension member for
the
>> last year is used? The last year in my dimension table
is
>> 2003. I do not understand syntax .item(0).Item(0)!

>> Thanks
>> Gary
>> >-----Original Message-----
>> >Well, if there was > 1 value for the member property,
its
>> values weren't
>> >going to be useful as default members without some
extra
>> thought..

>> >Are you saying that you wanted the default member to be
>> defined by the
>> >formula

>> >Ancestor([Time].currentMember,
>> >[All Time]).properties("process1WeekEnding")?

>> >This might not have worked anyway. At the time the
>> expression is
>> >evaluated, the current member of Time is [Time].[All
>> Time] anyway, and
>> >you unless you define the All level yourself in the
time
>> table, it can't
>> >have any member properties.

>> >With private dimensions, each can have a property with
>> the same-name,
>> >which will get around the problem. You could have 1
>> property named
>> >ProcessWeekEnding and an expression like

>> >StrToMember (
>> >  "[Time].["
>> >  + Tail (
>> >    [Time].[Year].Members,
>> >    1).Item(0).Item(0).Properties ("ProcessWeekEnding")
>> >  + "]"
>> >)

>> >to get the property from the most recent year. To use a
>> shared time
>> >dimension, you can define a hidden calculated measure
>> called [Cube Name]
>> >in each cube that returns the name of the cube, and
then
>> use the formula

>> >StrToMember (
>> >  "[Time].["
>> >  + Tail (
>> >    [Time].[Year].Members,
>> >    1).Item(0).Item(0).Properties ("Process" + CStr
>> ([Measure{ w? c ??""O?    s].[Cube
>> >Name]) + WeekEnding")
>> >  + "]"
>> >)

>> >where in cube ABC, it references
>> property "ProcessABCWeekEnding", in
>> >cube XYZ it references property "ProcessXYAWeekEnding",
>> etc. Just make
>> >sure that when you take the value of the member
property
>> and wrap

 
 
 

Cons for each Cube having private time dimension

Post by George Spoffor » Fri, 02 Aug 2002 23:28:10


Gary,

You're right, you need the Tail(). You also need .Item(0).Item(0),
because Tail() returns a set. The first .Item(0) returns a tuple, and
the second .Item(0) returns a member from the tuple. It's really a data
typing issue.

The client can't get the new default period before the refresh is done,
since the data load is transactional. If someone connects to the cube
while the cube is being refreshed, they'll get the old default, and then
during the session the new data will become available but they won't get
the new default, unless they reconnect or run a REFRESH CUBE statement.
Hopefully the timing isn't too big a deal here.


> The simplicity of this approach using formula
> Filter (
>   [Time].[Day].Members,
>   Not IsEmpty ([Measures].[<some measure here>])
> ).Item(0).Item(0)
> is very tempting.
> I presume that since a new period in its entirety is
> loaded to the cube each time the cube is refreshed then I
> think the client would get the new default period before
> all the new period data has been loaded ... but I guess
> will can live with this situation.
> .. but to get the value of weekending for the latest
> posting with a non empty measure shouldn't the formula be
> like

>   Tail(
>   Filter (
>   [Time].[WeekEnding].Members,
>   Not IsEmpty ([Measures].[<some measure here>])
>   )
>   )

> Thanks
> Gary

> >-----Original Message-----
> >That formula will only work best if the value
> of "Currentmember Date"
> >looks like "Time].[July 31, 2002", otherwise, it could be
> a little slow
> >because AS2K may need to search each dimension to find
> the member. I
> >imagine her discussion included other details- this looks
> pretty
> >representational. In my suggestion, it only needs to look
> like "July 31,
> >2002". I think it must have been intended for another
> context as well- I
> >can't imagine her suggesting this for use as a default
> member formula.
> >Consider what I said earlier about the "current member"
> when the default
> >is evaluated, as well as the lack of member properties at
> the [(All)]
> >level. Her formula gets you the current date of the year
> the current
> >member happens to be under, which is not what you are
> looking for.

> >Can you identify the processed period of the cube by the
> last period
> >that has data for some sentinel measure? If so, you could
> use:

> >Filter (
> >  [Time].[Day].Members,
> >  Not IsEmpty ([Measures].[<some measure here>])
> >).Item(0).Item(0)

> >as the expression in each cube.

> >Look at the BOL for .Item().

> >HTH


> >> I chose this formula based on a presentation by
> >> Hilary Feier called Dealing with time in a
> >> MultiDimensional space:
> >> StrtoMember ("[" +
> >> Ancestor([time].currentmember,[Year Name]}.properties
> >> ("Currentmember Date") + "]")

> >> Using your formula

> >> >StrToMember (
> >> >  "[Time].["
> >> >  + Tail (
> >> >    [Time].[Year].Members,
> >> >    1).Item(0).Item(0).Properties ("Process" + CStr
> >> ([Measures].[Cube
> >> >Name]) + WeekEnding")
> >> >  + "]"
> >> >)

> >> Does this mean that the last time dimension member for
> the
> >> last year is used? The last year in my dimension table
> is
> >> 2003. I do not understand syntax .item(0).Item(0)!

> >> Thanks
> >> Gary
> >> >-----Original Message-----
> >> >Well, if there was > 1 value for the member property,
> its
> >> values weren't
> >> >going to be useful as default members without some
> extra
> >> thought..

> >> >Are you saying that you wanted the default member to be
> >> defined by the
> >> >formula

> >> >Ancestor([Time].currentMember,
> >> >[All Time]).properties("process1WeekEnding")?

> >> >This might not have worked anyway. At the time the
> >> expression is
> >> >evaluated, the current member of Time is [Time].[All
> >> Time] anyway, and
> >> >you unless you define the All level yourself in the
> time
> >> table, it can't
> >> >have any member properties.

> >> >With private dimensions, each can have a property with
> >> the same-name,
> >> >which will get around the problem. You could have 1
> >> property named
> >> >ProcessWeekEnding and an expression like

> >> >StrToMember (
> >> >  "[Time].["
> >> >  + Tail (
> >> >    [Time].[Year].Members,
> >> >    1).Item(0).Item(0).Properties ("ProcessWeekEnding")
> >> >  + "]"
> >> >)

> >> >to get the property from the most recent year. To use a
> >> shared time
> >> >dimension, you can define a hidden calculated measure
> >> called [Cube Name]
> >> >in each cube that returns the name of the cube, and
> then
> >> use the formula

> >> >StrToMember (
> >> >  "[Time].["
> >> >  + Tail (
> >> >    [Time].[Year].Members,
> >> >    1).Item(0).Item(0).Properties ("Process" + CStr
> >> ([Measure{ w? c ??""O?    s].[Cube
> >> >Name]) + WeekEnding")
> >> >  + "]"
> >> >)

> >> >where in cube ABC, it references
> >> property "ProcessABCWeekEnding", in
> >> >cube XYZ it references property "ProcessXYAWeekEnding",
> >> etc. Just make
> >> >sure that when you take the value of the member
> property
> >> and wrap

--
George Spofford
Microsoft MVP
Chief Architect / OLAP Solution Provider
DSS Lab
http://www.dsslab.com

ISVs & IT organizations: Find out how DSS Lab can speed your
development!
 
 
 

1. Virtual Cube - Private Dimension

Hi All,

We have got 3 source cubes with the private dimensions.
(Even though all the 3 cubes refers to the same dimension
table, they have been associated with the cube as private
dimensions)

We tried to build a virtual cube with the 3 source cubes.
When we tried to define dimensions to the virtual cube, we
could find that the list of available dimensions shows the
dimension names 3 times followed by the cube name in the
bracket. We included all the dimensions of a particular
cube and built the cube.

While browsing the data (with some filters on), the data
of all the cubes except the Cube whose dimension had been
included while defining the dimensions of the virtual cube
are not shown.

Is it that when I create a private dimension in a cube,
that dimension cannot be used across other cubes inside
the Virtual Cube.

Thanks for your time.

Cheers,
Sanka

2. Inserting multiple values

3. Create a virtual cube from two cubes with different time dimensions(levels)

4. Programmer/Analyst Position, Irvine, CA USA

5. inventory cube but 4 time dimension are used...

6. Max database size ...

7. Time Dimensions In Local Cube

8. trapping error in stored proc

9. Multiple time dimensions in a single cube

10. Converting from MSOLAP to a local cube file - ordering of time dimension

11. Time dimension members sorting improperly when fetching cellset from cube

12. Count of dimension in cube; levels in dimension

13. How can I add a private time dimension to a Cube via DSO?