I would go on DMR’s because of:
- single point of data delivery, no special routines for cube building, schedules, etc
- single point of providing data security — only FrameWork Manager, no propagation of rights to Transformer
- ability to use attributes and multiple languages — if you’re thinking of Transformer.

With following remarks:
1) Make sure that your DW design is good for reporting. If you’re having dimensions of the same size as fact tables — it seems a bit strange. Maybe you’re trying to catch to much history in dimension, whereas it should be in fact table? Like employees moving from one dept to another, or customer address changes. But it depends on subject area as well.
2) Make sure that you’re having decent hardware for DBMS – for 10s of millions any ‘mid-server’ (2-4 CPUs, 16G of Ram, normal I\O — a RAID5 or 10 controller with 5-10 disks) will suffice
3) Make sure that you get all of your DBMS — use 64bit version, use DW-features of your DBMS (bitmap indexes, materialized views for Oracle, MQT, MDC for DB2) and spend some time designing indexes for your schema.

I’ve personally used DMR’s over 100mln rows (in a very compact fact table, around 10gb size) — all was well enough.

- Yuri.

Have been in the same boat to decide to go with DMR or with Cubes.

We have few large dimensions (5mln-10mln records), few large facts tables (again 5mln-10mln records) and rest other tables with maybe less records or so..in our DW.

Currently, we have a relational package, canned reports and ad-hoc reports based on this relational package.

The main business need is for ad-hoc and analysis.

DMR sounds appealing, as we have the realtional foundation. But, will DMR have performance issues
Or going the cube route will be more appropriate?

Appreciate if some expereinces are shared or any suggestions.

Thanks,

Just for other readers — multifact DMRs work )

- Yuri

Please share your thoughts!!

I usually try to avoid 1 where possible (on Oracle sites, it means) by adding Materialized Views.
Agreed on all other points.
TM1 will change dimension limits a bit, it seems )

Security will remain a main issue though.

Thanks for sharing,
Yuri.

Cubes vs. DMR:
Timeliness – Contain “real time” data (DMR); Data in cubes need to be updated (Cube).
Flexibility for user – Static (DMR); Dynamic (Cube).
Usage – Management/Statistical reporting (DMR); Reporting and Analysis (Cube).

Then it’s always too much important to find out about dimensions to use in one Cube, ~4-5 it’s pretty critical amount on my mind.

And I cannot say anything about security. Lots of time I had to refuse from start using Cubes when the security scheme was pretty complicated with a lot of dynamic combination especially when I read security information from RDBMS.

Good Luck!

Now I am reviewing some approachs and architecture defined by the external consultants that have worked on our Cognos BI… All of our relational star schema data is referenced in Cognos by DMRs, but as far I can see it’s the WORSE option for large tables, specially for this full table scan behavior, no matter what filters we use…

But if it is not the best option, which one could be? Configure ‘pure’ relational model in Framework Manager? Powercubes are very restrict because the attributes are not available.

By the way, congratulations for the blog.

You use analytical functions like PeriodsToDate to get the set of months and apply some aggregation like “total [Sales]” over this set. It’s relatively easy and Cognos handles SQL generation. That’s what DMR’s are good for.
You can store these values, but I wouldn’t be bothered with that untill you reach serious data volumes (10-100 mlns of rows in fact tables).

— Jason