Hi SQL/OLAP Gurus,

I am new comer to OLAP with Analysis Service.
What are the considerations to decide to use OLAP (e.g: with Analisys
Service) or to use just 'traditional' reporting ?

(what I mean by 'traditional reporting' is reports on the operational/OLTP
database, not the OLAP database)

Thanks for your info,
Krist

"Krist" <xtanto (AT) hotmail (DOT) com> wrote

Not to be smug but you should use OLAP when OLAP is appropriate, and you
should use traditional reporting when traditional reporting is appropriate.
Your choice depends on your requirements. You'll have to provide more
information if you require a more specific answer...

HTH

"Domenico Discepola" <joeminga (AT) yahoo (DOT) com> wrote:
on when a data warehouse is needed over reporting off of the application
database. Most folks start down the DW path when they have multiple applications
all doing the same thing. These systems were written at different times
using different technologies. Now the business wants seamless enterprise
reporting for multiple disparate systems. There's also performance and historical
considerations although these could be addressed through other means.

I agree and disagree with you ;-) IMHO, an enterprise should tackle a DW
project only when it is ready to do so. I read somewhere (I think in one of
Ralph Kimball's articles) that an extremely high number of DW projects fail
simply because organizations don't know what they're getting themselves
into. There may not be a need to build an 80-floor office tower when a
little tent will suffice... A DW should be driven by business requirements
and not by IT. It's IT's job to recognize the business requirements and
address them with a DW, if one is appropriate.

Just my humble $0.02

"Domenico Discepola" <joeminga (AT) yahoo (DOT) com> wrote:

xtanto (AT) hotmail (DOT) com (Krist) wrote in message news:<cb48a3b.0401140550.3ef69ce8 (AT) posting (DOT) google.com>...
Kirst,

Organisations need information on their performance to help make
decisions about future action.
The information that is required is usually highly aggregated, e.g.
total sales by product category or total costs by department, etc.
It is the AGGREGATED nature of this data that is addressed with OLAP.
OLAP ensures speed because most of the aggregated values are
precalculated.
Such highly aggregated values are required in management information
reports.
So use a front-end on Analysis Services that can create these
management information reports.
There are some good Excel add-ins that can:
1. Build reports easily
2. Can be used by end-users easily
3. Make use of spreadsheet functionality
4. And can do the ad-hoc analysis as well.

If you don't want to use Excel there are web & window client
front-ends as well.

I work for www.MISag.com they have an Excel add-in called Plain & a
windows/web client called OnVision.

No doubt other vendors will now weigh-in with their products, but the
essential message is use OLAP for both reporting & ad-hoc analysis.
The exceptions are:
1. Where reporting is based on transactional level & is used in the
day to day operation of the organisation
2. When static reports are sufficient; reporting can be done off of
the datawarehouse overnight.

Dynamic reporting off of OLAP is the way to go!

Regards,

John

Personally I have the following simple rules when to use OLAP:

- Many users quick responsetime required
- Queries against AGGREGATED data primarely
- Flexible reporting (slice and dice....)
- Advanced calclations (financial, time, forecasts etc)
- Read/write like budgets and analysis
- medium to large datavolumes

I think several of these requirements should be met!

RE
Bjørn T

duvinrouge (AT) servihoo (DOT) com (John Keeley) wrote in message news:<542fe31c.0401190134.78eaed7 (AT) posting (DOT) google.com>...