....on one cube?

I'm developing in SSAS 2005 running on dual core dual Opteron 64 bit machine.

I know. It sounds like a lot of dimensions. But sometimes the world is
really complex and your cubes get complex, too.

Anyone have any experience with this? Anyone have any advice on this.

--
Bob Hodgman

you are right... 800 is really huge!!!

does it's really dimensions or attributes?
how the system performs?

your problems come from the end user access, this a lot of metadata to play
with.


"Bob H." <BobH (AT) discussions (DOT) microsoft.com> wrote

Not sure if this is still a constraint in AS05 but there is a 256 level
limit in AS00...

Agreed though sometimes the world is a bit complex, no matter how much
we try and boil it down to the bare essentials.

*** Not knowing your objective*** If you're not sure if all of the dims
are needed, you may want to run some significance tests to determine
the ones that have impact on your KPIs

Would attributes be more efficient than dimensions? I've got this up and
running, but the response time is slow (60 seconds to display results).

Visual Studio (2005 - 32-bit Visual Studio on the dual Opteron x64 system)
could not deploy the cube (system out of memory!). I had to write scripts and
run them through xmla query windows in Management Studio.

Thanks!
--
Bob Hodgman


"Jéjé" wrote:

So far, so good... SSAS 2005 isn't limiting me on the number of dimensions. I
was able to build and process the cube with the 800 dimensions (Visual Studio
2005 choked on doing the job - I had to work with xmla scripts in a query
window in Management Studio).

It's a bit slow - especially on DISCOVER MDSCHEMA operations. I'm thinking I
might need to tune the SSAS installation or the server OS installation.


--
Bob Hodgman


"BK" wrote:

My interpretation of the question on attributes was: can you group the
dimensions together into larger entities?

For example, if your 800 dimensions look a lot like:
[Flag1], [Flag2], [IsDeleted], [IsAvailable], etc.
Then can you combine all these types of attributes into somehow logical
groups and create a dimension that has a large composite key attribute and
lots of related attributes with the actual flags?

Can you give a summary of what your 800 dimensions look like?

Thanks,
Akshai
--
This posting is provided "AS IS" with no warranties, and confers no rights
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

"Bob H." <BobH (AT) discussions (DOT) microsoft.com> wrote

yes, a sample of your dimensions can help us.

if you have 800 dimensions, I presume that you have more then 800 columns in
your fact table???

just for my personnal knowledge... what is this cube? ;-)
a survey cube?

"Akshai Mirchandani [MS]" <akshaim (AT) online (DOT) microsoft.com> wrote

The 800 dimensions represent questions on a questionaire. The answers are all
mutiple-choice. The answers can be Yes/No/Unknown or an item from some other
static list of possible answers (like red/green/blue/pink...).

The purpose of the cube is to allow a group of analysts to find out how many
answered "yes" to question #95, "blue" to question #566 and "Chocolate chip"
to question #122 (for example).

There are logical groups of questions. Would creating combined keys still
allow the full flexibility to interrogate the data?

Thanks!





--
Bob Hodgman


"Akshai Mirchandani [MS]" wrote:

Yes, Jéjé, it is a survey cube. And yes, there are more than 800 columns in
the fact table!

See my response to Akshai for sample dimensions. The dimensions are the
range of answers to the survey questions (always from a static, pre-defined
list of answers).

Thanks for your help on this!

--
Bob Hodgman


"Jéjé" wrote:

Yes, lets take a non-survey example:

Country
\
State
\
City Age
\ /
Customer

If this is your dimension definition, and you want to find the Sales for
Customers living in [State].[WA] in the Age group [20-30], you can just say:

SELECT [Measures].[Sales] ON 0
FROM [Sales]
WHERE
( Customers.State.WA, Customers.Age.[20-30] )

The server will aggregate up the data from the customers that match *both*
conditions.

The same thing can be done for the survey example except that here the key
wouldn't really be a very useful attribute except for the unification of the
survey results.

I would suggest building a small sample to prove the concept and then extend
it to your full domain.

In addition, I would recommend building the dimensions from real dimension
tables where possible so that processing of the dimensions doesn't involve
the fact table -- in fact, I would also recommend having integer keys for
the yes/no type answers to improve processing speed of the partition data.

Thanks,
Akshai
--
This posting is provided "AS IS" with no warranties, and confers no rights
Please do not send email directly to this alias. This alias is for newsgroup
purposes only.

"Bob H." <BobH (AT) discussions (DOT) microsoft.com> wrote