Shaab

You definitely do not need Essbase to do the reporting and analysis you
require.

Install and use Microsoft Analysis Services. This is found on the same SQL
Server 2000 disk if you have not installed it yet. There are some useful
tutorials so you will need to have a look at these.

With respects to front end reports and analysis, O2OLAP can give you an easy
option to assist in your reporting and analysis. If you want to see O2OLAP
in action, together with Microsoft's Analysis Services, then please feel
free to contact me for a live demonstration through your web browser and
while you are at your desk. Have a look at our web site as well.

Regards
Howard.Taylor@ domain below.
www.o2olap.com



"shaab mohagir" <shaab.mohagir (AT) bonbon (DOT) net> wrote

"shaab mohagir" <shaab.mohagir (AT) bonbon (DOT) net> schrieb im Newsbeitrag
news:e1b3da1b.0308110651.7ccae483 (AT) posting (DOT) google.com...
Shaab,

Hyperion is a multidimensional data base, not a relational. In this point it
directly competes with Microsoft Analysis Services which is shipped with SQL
Server by Microsoft and which you can install from the SQL Server CD.
Multidimensional data bases (MDDB) have in brief some advantages over
relational data bases i.e. better performance if you store a reasonable
amount of data in it, better write-back or planning support, a calculation
engine, etc. In a data warehouse scenario the limitted data volume and
better performance of MDDBs often lead to a hybrid technology by using both
a MDDB and a RDB. MDDBs are usually used as a store for aggregated data
(tell us more about your data volumes, if you want to have a clear statement
how to design the data storage) and RDBs as a store for mass data. There are
many more reasons to use both.

Why did you ask about Hyperion Essbase? Does your company already own
licenses? If not I would suggest to look at your end users' requirements,
tell us a bit more and get some advice which front end/data base combination
to use and not to be convinced by sales people to look at their solution
without them knowing what you want to do.

You know, in fact an Excel front end can help you a lot for certain end user
requirements, whilst it will give you pains to be used for covering others.

Kind regards,

Joerg

Shaab,

if you're using SQL Server 2000, the Analyis Services will handle the
requirements of your users usually.

Hyperion consultants or resellers may have an other point of view ...

Regards.

minimax / Thomas

Sounds like you've got a few options on your hands. First off, kind of
too bad that somebody bought Essbase without ever doing any requirements
analysis, then left the company (or maybe that was on purpose....).
Either way, if you've got the data strucutred in SQL Server already,
you've got a few things you could do from an architecture standpoint.

I've built Essbase applications based on star-schema data warehouses
in SQL Server, and they do work pretty well. One drawback is that
the Essbase-to-SQL Server SQL interface is kind of shaky, so you'll
want to test it out if you go that way. Otherwise, with large
transaction volumes, Essbase handles it pretty well (if you tune it
to do so), and you've still got the option of storing summary level
data in Essbase, while allowing the drill-through to the RDBMS for
transaction level data.

At a high-level, Essbase is a very powerful platform, with a robust
suite of functions that allow you to manipulate your data within the
database through calculations and load rules to do just about anything
you want. The downside of Essbase is that it requires alot of training
& experience, and can turn out to be maintenance heavy.

If you were willing to throw Essbase to the wayside, depending on your
users requirements (which eventually you'll have to go through the
exercise of gathering), you really could use Analysis Services to do
most of what the organization needs. The integration from Analysis
Services to the RDBMS is probably going to be a bit more stable, you may
lose a little in the way of functions, but overall Microsoft has come a
long way with that platform. Remember that either way, you're going to
need to put some sort of front-end onto the MDDB, so that users can play
with the data.

So to answer your original question, you don't need to use Essbase. But
you probably do need to use some sort of MDDB, with a hybrid storage
architecture allowing you to get transactional data from the RDBMS.
Just a thought.


E

--
Posted via http://dbforums.com

I also recommend you go with Analysis Services.
Then look at some of the relatively inexpensive Excel add-ins:
XLCubed, MIS Plain, etc

"Nigel Pendse" <nigelp.nospam (AT) compuserve (DOT) com> wrote

Yes, I stand corrected. I mean Essbase, not OLAP. And yes, not all
data is stored, you are correct there too. But, some change to data at
low levels or the database in a cube the size mentioned above can take
hours to days to calc (even if you are only doing sections, and you
would need help to do it in sections (or the class)). But why go to
Essbase alone, with one person, when they have SQL Server? Yes, it has
some good points, but I did that and it's a two year thing w/ no
experience. Reports have to be perfect to go to the CEO and big guys,
and that's just the tip, of the tip, of the iceberg. It's a full time
job for one person, and unless you have nothing else to do. Stay away
from Essbase alone! Get team and go to school and get some help, have
a large plan, sure! But that's the only way for success before Feb
2004.

It sounds like you went about your Essbase efforts the exact way that
most people recommend you don't do it. Not educating yourself on the
product & its capabilities, as well as data management principles and
skills will always leave you in the dark. One of the great parts about
Essbase is that if something changes at a low level in the database, you
can selectively reload & calc just the affected portions, which would
alleviate your calc time pain. Also, there are ways of structuring your
database that will significantly bring your calc & query times down,
which you may not have been aware of.



There are a bunch of other items I would bring up, but I don't think
they would be constructive. I am in the same camp as you, agreeing that
Analysis Services is a much better option, especially given that they
already have SQL Server in house. I do not agree that it will be any
easier for them if they don't go through the appropriate implementation
steps, as they will constantly hit roadblocks & pitfalls along the way.



Sorry for the little rant here, but I don't think you should be slamming
a product without having full knowledge of it. However, I do agree with
your conclustion.





E


--
Posted via http://dbforums.com

I'd like to share with you my experience as an Essbase developer and
administrator.
I agree about the effort required to deliver a whole Essbase
application.
We have the experience of deploying a whole application (from the
estimates to the user acceptance test), in 3 months using 1
experienced person for the Essbase database part and 3 persons for the
Executive Reports part.
Regarding the amount of data to store in an Essbase cube and the time
of re-calculation of the database, I was checking at one of the
applications my team has developed and currently in maintaining. It is
loading more than 66.000 distributors and business partners and like
150.000 products, With out problems.
Also, we have other applications that size in the order of gigabytes.
Of course, we work on powerful servers (AIX, 4 Power PC processors + 3
Gb RAM).
The refresh processes start at midnight, and the database use to be
ready for use at 8.00 AM after generating tons (sometimes thousands)
of reports.
The whole run is automatic. And we allocate like 1 person corrective
maintenance, and another 1 for development and changes.

Like the other guys say, Essbase is powerful but you need either
training or a couple of developers to assist you.

Hope this clarify a little more.

Regards,
Marcelo Narvaja

ericdkauff <member35486 (AT) dbforums (DOT) com> wrote