What are the limits of a business objects universe as far as data manipulation is concerned?

Question

I'm being asked to get involved in migrating a large suite of reports from SAS to Business Objects. The existing SAS reports all use Base SAS code to query a transactional database; though they are called reports, they actually contain a large amount of data manipulation.

Although I have never used Business Objects, I am aware that a universe is able to apply simple mappings (e.g. giving different names to fields), transformations (e.g. concatenating fields, or doing a sum or average), and is able to join tables. The question is: how extensive can the data manipulation be within a universe? Will I be able to emulate SAS code that uses complex SQL, or multiple temporary tables as stepping stones in a long calculation, or procedural logic? At what point will I have to use an ETL tool to do these manipulations and create an underlying "reporting layer" in the database?

Answer 1

The BusinessObjects universe is simply a metadata layer; it does not store data like SAS datasets or Cognos cubes. Fundamentally, the function of the universe is to construct a SQL statement that will be used to create the "microcube" which is then used as the source data for a single report. So, procedural functions, like the creation of temp tables, is not supported. One possible workaround for this is to use stored procedure universes -- this allows the universe to call a stored procedure, and use the results that it returns. The stored procedure, of course, can create temp tables if appropriate.

With that said, the SQL that BO creates can be fairly complex. For example, contexts in universes enable a report to be created that uses fields from multiple fact tables, in order to avoid chasm/fan traps If the universe is structured properly, the query engine will construct multiple SQL statements -- each one using one fact table and associated dimensions. The multiple result sets are then joined together in the report, and presented as a single report block.

So, bottom line, if you need to pre-load or pre-calculate data for consumption by BO, you are most likely going to need an ETL process. If the desired result can be accomplished using straight SQL, then BO can probably do it.