2

I am interested in comments and insights relating to using Microstrategy to report against a complex snowflake SQL Server database comprising of several transactional, normalized (3NF) tables.

Specifically, what is the best approach or the challenges on reporting in such an environment? Currently, there are some complex views that serve as analytical fact tables using complex SQL joins between the several transactional tables.

The transactional tables also have their own dimensions, and so on. The views seem to work fine in SSRS. However, I have read that Microstrategy is not ideal for reporting against such a complex database (not due to performance of the tool, but more so because of the complexity of the SQL in building these metrics in Microstrategy).

What would be the best approach on reporting in such an environment? Would building an SSAS cube on the current data warehouse be a good idea? Should reporting be done on the database, or should a new database or mart be created, specifically to be used by Microstrategy, with only the relevant views for basic reporting?

Any advice or opinions are appreciated.

4

4 に答える 4

3

I don't know if this is still an active thread, but here are some thoughts.

Transaction databases, in my opinion, are not the best for reporting BI. The relational model works well for day to day reporting and for operational reporting.

However once you decide to generate BI reports, you need to be using a Dimensional Model for your Data Warehouse. I have learned this through hard experience. And this is a rule not just for MicroStrategy, but also for any software product that hopes to do BI reporting.

There are a number of reasons for this statement. I won't go into all of the reasons. Your best bet is to get any of the excellent books by Kimbal on Dimensional Modelling.

I have tried to use several different reporting packages, including MicroStrategy, and the biggest determinant of whether your project will work or not is whether your have a good dimensional database design for your BI Warehouse. This of course means using some sort of ETL process to transform relational data into dimensional data.

Hope this helps.

于 2013-09-24T15:24:10.003 に答える
1

No matter what reporting tool you use, you will have performance issues if you have complex snowflake joins in the background. This is because every user that runs a report will cause the same SQL to be run - some tools have clever caches, but this falls down when you have user selected prompts.

A SSAS cube is a good option as long as your users feel comfortable with this, but the ideal way is to have aggregate tables for your data (you could call this a mini datamart ) that are designed for your reports.

This works only if you can afford the time for the aggregate tables to be refreshed - if your users need real time data, this isn't really an easy option, but otherwise you can schedule an aggregate procedure to run at set intervals.

The real beauty of this, is that your aggregates can be tailored to your reports and you can get amazing performance.

于 2013-03-25T13:03:49.367 に答える
1

I used Microstrategy tools many years ago. My comments may not be upto date. At that time it was a perfect rolap tool against star schema. It can generate many optimized SQL statements to provide result set. However it was not working fine on 3rd normal form db.

In a 3rd normal form db, I would suggest an alternative tool, like business objects which can handle any kind of db structure. I have seen a business ojects universe on top of an re-insurance OLTP system with 5000+ 3rd normal form tables/views and that was working fine. But when you start using 3rd normal form, it is difficult to deliver correct results for all possible queries and also it will be a lot slower compared to denormalized star schema.

于 2013-04-04T11:58:54.100 に答える
1

If you know what you're doing on the SQL side, and know how the SQL generated by MSTR needs to change to avoid the hidden joins, then you can use a logical table, added to the relevant attribute forms, to affect the generated SQL directly. Look up logical views.

于 2013-09-12T23:19:55.717 に答える