Can I create OLAP Cubes without a staging area?

I have de normalised tables in the source for use in a star
schema.However the grain of the facts that I may need are different
from that in the source also the source database has got denormalised
database which has data according to the three diferent companies
where the data is generated...
Can i build views not move the data and create cubes...how do i deal
with Unassiged if I do so?
Does anyone have an Idea how to deal with unassigned values without
creating a fact table based just on views from the source?
Thanks in anticipation...
AjayYes you can certainly build cubes off relational sources, to handle
unassigned values, you could use the isnull function. If you do end up using
a fact table, you can create "unknown" values in your dim tables that still
link to the fact table.
Not clear if this is what you are asking or not..
Ray Higdon MCSE, MCDBA, CCNA
--
"Ajay Garg" <ajayz90@.hotmail.com> wrote in message
news:d9477327.0403170556.173c077c@.posting.google.com...
> I have de normalised tables in the source for use in a star
> schema.However the grain of the facts that I may need are different
> from that in the source also the source database has got denormalised
> database which has data according to the three diferent companies
> where the data is generated...
>
> Can i build views not move the data and create cubes...how do i deal
> with Unassiged if I do so?
> Does anyone have an Idea how to deal with unassigned values without
> creating a fact table based just on views from the source?
>
> Thanks in anticipation...
>
> Ajay

Can I Alter A Report that has already been deployed to my Report Manager

I have some OLAP reports in which I have to alter the MDX statements each month, in the VS2005 report designer. They are deployed to the web and they contain Descriptions and Subscriptions which I create once they get to the web. The way I am currently updating them each month is by editing the reports in VS2005 and re-deploying them to the Reports Server. I then have to add the descriptions again and create new Subscriptions because the orig reports are deleted when the new ones, with the same name are deployed. There has to be a way that I can just alter the existing reports in the web environment and not have to recreate the Subscriptions each month. Any help would be appreciated.

If you go to the actual report that you want to update in report manager and go to the general tab there is a button that says update that you can select and then upload the new version. Then all of your descriptions and your history will remain and you just upload the new version of the report.

Properties-General-Update-Do not forget to hit apply when finished choosing rdl file.

Can I add user and passw to my OLAP ConnectionString?

Hi all,
I have written a custom assembly that works fine in preview mode, but when I deploy the report I get the '#Error' message instead of the output.
I have copied the assembly to the bin folder of Reportserver, placed it in the GAC and even edited the policyfiles.

Any help would be very appriciated,

Thanks in advance

public static class SimCardBuyer
{
public static string ReturnBuyer(string Seller, string PeriodeCode, string ComDevice)
{
string connstring = "PROVIDER=MSOLAP;DATA SOURCE=srv03-gc-10;INITIAL CATALOG=Invoicing";
AdomdConnection conn = new Microsoft.AnalysisServices.AdomdClient.AdomdConnection(connstring);
//Create a new string builder to store the results
System.Text.StringBuilder result = new System.Text.StringBuilder();
//Connect to the local server
using (conn)
{
conn.Open();
//Create a command, using this connection
AdomdCommand cmd = conn.CreateCommand();
cmd.CommandText = @."SELECT NON EMPTY { [Measures].[InvoiceAmount] } ON COLUMNS, NON EMPTY { ([Buyer].[Company].[Company].ALLMEMBERS ) }
DIMENSION PROPERTIES MEMBER_CAPTION, MEMBER_UNIQUE_NAME ON ROWS FROM
( SELECT ( { [Com Device].[Com Device].[" + ComDevice + @."] } ) ON COLUMNS FROM
( SELECT ( { [Invoice].[Period Code].[" + PeriodeCode + @."] } ) ON COLUMNS FROM
( SELECT ( { [Seller].[Company].[" + Seller + @."] } ) ON COLUMNS FROM [Invoicing])))
WHERE ( [Seller].[Company].[" + Seller + @."], [Invoice].[Period Code].[" + PeriodeCode + @."], [Com Device].[Com Device].[" + ComDevice + @."] )";

//Execute the query, returning a cellset
CellSet cs = cmd.ExecuteCellSet();
//Output the column captions from the first axis
//Note that this procedure assumes a single member exists per column.
TupleCollection tuplesOnRows = cs.Axes[1].Set.Tuples;
if (tuplesOnRows.Count > 1)
{
for (int row = 0; row < tuplesOnRows.Count - 1; row++)
{
result.Append(tuplesOnRows[row].Members[0].Caption);
result.Append(" / ");
}
result.Append(tuplesOnRows[tuplesOnRows.Count - 1].Members[0].Caption);
}
else if (tuplesOnRows.Count == 1)
{result.Append(tuplesOnRows[0].Members[0].Caption);}
else{result.Append(Seller);}
conn.Close();
return result.ToString();
}
}

Dear readers,

I have solved the problem above, but now I get an error with the Connectionstring.
I'm getting the next error now:

Either the user, NL01\SRV03-GC-10$, does not have access to the Invoicing database, or the database does not exist.
NL01\SRV03-GC-10$ is not a user in my system, so I'm stunned with this strange error.

I would appriciate any reply on this.

regards.

Can data be queried in OLAP cubes as in Views?

This question may appear a bit pedestrian but nonetheless.

We are in the process of building OLAP cubes for data analysis purposes. The question that we have is simply can we access the data stored in the OLAP cube in the same way that we would a View. We utilise a simple VB reporting tool that allows us to dynamically interrogate views in our SQL databases. Would this functionality apply also to OLAP.

Regards

RepomanYou can build a cube off of a single table or from a view.

HTH|||I didn't try it yet, but I know that SQL Server has a different OLE DB provider for it's analytical services. You will need to use it to connect to your cube.|||After further research it appears that we cannot just plug directly in. I think we need to use MDX to call the Cube. The resultant data can then be passed to our report builder.

Many thanks for the answers nonetheless.

Regards

Repoman|||Guess I'm not clear on what you are asking. If you build your cubes with ROLAP (relational - OLAP) the cube will build/store your cube in a relational matter. MDX you can use to build calculated members on a cube, what is it you are trying to do?

Can a single table be used for cube?

Hi,
Maybe a silly question since I am new to SW/OLAP/etc. etc.
I was wondering that if I have a single table having all the things that
can be used as 'measures' PLUS all the possible information about
dimensions in the same table.
Basically this would end up with a highly un-normalized table but
wouldn't it give a very good performance since there will be no joins
required.
I'll appreciate feedback and guidance from the experienced audience.
Thanks.I'm not sure it would give good performance. Consider a star schema with a
date dimension, for example. To know what values are available for the dime
nsion, it's compacted into this nice small table that only has to deal with
dates. If you denormalized
all of that into one table, then you'd have to scan the whole table to know
what dates are available for slicing and dicing.
If you did that with all of your dimensions, you'd end up having to scan the
whole table several times to get all of the possible values for slicing and
dicing. You could, I suppose, index those, but now you've created some ove
rhead where you didn't have
it before.
Besides--and I'm just guessing here--I would think that under the covers the
re's not really a join going on anyway. The IDs for the dimensions are prob
ably used for retrieving data from the fact table.|||Hi,
Thanks for the reply. Based on my findings over the past few days, I
have concluded that having only a single table to be used for the fact
table as well as dimension will be a VERY BAD APPROACH so I agree
with your suggestions.
To answer your question: Yes I wan not planning on any joins... the
single table would have been being available after running a DTS over
night which would have done the joining which many tables to give me the
single highly un-normalized table...
But you know what; to be honest this is where I do get a little confused
though because though there are many advantages of normalization, the
performance from an un normalized table is supposed to be far
superior... I guess the counter argument to this would be your own
comment I.e. "If you did that with all of your dimensions, you'd end up
having to scan the whole table several times to get all of the possible
values for slicing and dicing..." and as I understand and assume, this
would result in the calculated aggregations taking up a lot of space on
the Hard disk (server's or local PC's - depending on whether I am using
ROLAP, MOLAP, HOLAP, WOWLAP )
Please DO comment in response to my mail as it will help my confirm my
understanding of many things so far.
Thanks again for the reply and regards.

> I'm not sure it would give good performance. Consider a star schema with
a date
> dimension, for example. To know what values are available for the dimensi
on, it's
> compacted into this nice small table that only has to deal with dates. If
you
> denormalized all of that into one table, then you'd have to scan the whole
table
> to know what dates are available for slicing and dicing.
> If you did that with all of your dimensions, you'd end up having to scan t
he
> whole table several times to get all of the possible values for slicing an
d
> dicing. You could, I suppose, index those, but now you've created some ov
erhead
> where you didn't have it before.
> Besides--and I'm just guessing here--I would think that under the covers t
here's
> not really a join going on anyway. The IDs for the dimensions are probabl
y
> used for retrieving data from the fact table.
>

Can a single table be used for cube?

Hi,
Maybe a silly question since I am new to SW/OLAP/etc. etc.
I was wondering that if I have a single table having all the things that
can be used as 'measures' PLUS all the possible information about
dimensions in the same table.
Basically this would end up with a highly un-normalized table but
wouldn't it give a very good performance since there will be no joins
required.
I'll appreciate feedback and guidance from the experienced audience.
Thanks.
I'm not sure it would give good performance. Consider a star schema with a date dimension, for example. To know what values are available for the dimension, it's compacted into this nice small table that only has to deal with dates. If you denormalized
all of that into one table, then you'd have to scan the whole table to know what dates are available for slicing and dicing.
If you did that with all of your dimensions, you'd end up having to scan the whole table several times to get all of the possible values for slicing and dicing. You could, I suppose, index those, but now you've created some overhead where you didn't have
it before.
Besides--and I'm just guessing here--I would think that under the covers there's not really a join going on anyway. The IDs for the dimensions are probably used for retrieving data from the fact table.
|||Hi,
Thanks for the reply. Based on my findings over the past few days, I
have concluded that having only a single table to be used for the fact
table as well as dimension will be a VERY BAD APPROACH so I agree
with your suggestions.
To answer your question: Yes I wan not planning on any joins... the
single table would have been being available after running a DTS over
night which would have done the joining which many tables to give me the
single highly un-normalized table...
But you know what; to be honest this is where I do get a little confused
though because though there are many advantages of normalization, the
performance from an un normalized table is supposed to be far
superior... I guess the counter argument to this would be your own
comment I.e. "If you did that with all of your dimensions, you'd end up
having to scan the whole table several times to get all of the possible
values for slicing and dicing..." and as I understand and assume, this
would result in the calculated aggregations taking up a lot of space on
the Hard disk (server's or local PC's - depending on whether I am using
ROLAP, MOLAP, HOLAP, WOWLAP )
Please DO comment in response to my mail as it will help my confirm my
understanding of many things so far.
Thanks again for the reply and regards.

> I'm not sure it would give good performance. Consider a star schema with a date
> dimension, for example. To know what values are available for the dimension, it's
> compacted into this nice small table that only has to deal with dates. If you
> denormalized all of that into one table, then you'd have to scan the whole table
> to know what dates are available for slicing and dicing.
> If you did that with all of your dimensions, you'd end up having to scan the
> whole table several times to get all of the possible values for slicing and
> dicing. You could, I suppose, index those, but now you've created some overhead
> where you didn't have it before.
> Besides--and I'm just guessing here--I would think that under the covers there's
> not really a join going on anyway. The IDs for the dimensions are probably
> used for retrieving data from the fact table.
>