Comments on: SQL Aggregate Versus Universe Projection

By: Dave Rathbun

Dave Rathbun — Tue, 27 Oct 2009 20:28:18 +0000

Hi, ilangovan, thanks for your comment. I am not sure I follow your question. Are you suggesting that in order to drill on a document that the database aggregation has to be turned off? If that is the case, then that’s not correct. When you drill on a report and set up a hierarchy the lowest level of detail is already retrieved on the report. Then the data is projected to the top level of the hierarchy until you drill. But imagine if you had millions of rows in your fact table, you would never want to return that level of detail to a report. Ever.

By: ilangovan

ilangovan — Tue, 27 Oct 2009 00:09:20 +0000

Dave,

I am a regular visitor to your blog!..

I disagree with this article of using database aggregation in measure object.

If the report require to drill down from top most aggregation to lowest grain level, then how to use the database aggregate function..?

Thus it is based on the requirement of the report, we should decide.

Thanks!

regards,
ilangovan

By: Jon Fortner

Jon Fortner — Tue, 06 Oct 2009 22:09:01 +0000

Thanks Dave as usual your contributions to the community are stellar. I first check the joins for loops, fan/chasm traps, then I ensure measures are properly defined. How about you?

By: Shiva

Shiva — Tue, 25 Aug 2009 08:51:15 +0000

Hey Dave thanks for the posts…Aggregate Vs Universe Projection and the Database Delegated Measure.
BOth are just AMAZING.

Increase your frequency of posting topics. :p

Regards,
Shiva

By: Josh Fletcher

Josh Fletcher — Thu, 09 Jul 2009 02:53:11 +0000

Hi Dave, I think the first thing I’d look for would be multiple unattached schemas (which would result in cartesian products) – I’ve seen that many times as well.

By: James Halligan

James Halligan — Tue, 07 Jul 2009 20:09:40 +0000

Hi Dave, heartily agree with this post. It is a timely reminder of the pitfalls of a poorly designed universe. I believe those universes without properly aggregated measures is sometimes done to successfully circumvent potential SQL traps and forces all the aggregation (and intelligence) onto the face of the reports. Indeed one of the real issues with not building universe measures is that you once you have gone down this road, you are stuck with. Web Intelligence queries do not react very kindly if you try to combine these “non-aggregated” measures with measures that attempt to something a little smarter eg the use of CASE statements in conjunction with @PROMPT to generate Year to Date and Month to Date figures

By: Dave Rathbun

Dave Rathbun — Tue, 07 Jul 2009 14:17:31 +0000

Vajravelu, welcome and thank you for the comment. What you say is certainly true but it’s far from optimal in many cases. The universe design is supposed to ensure consistent results. If each report writer is required to reinvent the wheel (so to speak) and create variables for sums and counts, there is a chance for inconsistent results. In addition to that, without a SQL aggregate, the report is returning far more data than is required.

Josh, measures are the second thing I look at when called upon to review a universe. Does anyone care to guess what the first (and most important, in my opinion) might be?

By: Josh Fletcher

Josh Fletcher — Tue, 07 Jul 2009 12:38:11 +0000

great post Dave, I find this is often something that is misunderstood by many Business Objects developers. the number of universes I’ve seen with no aggregation functions in the Select clause of measures are too many to count!

- Josh

By: Vajravelu

Vajravelu — Tue, 07 Jul 2009 11:17:22 +0000

Hi David, By BOE roll Designer has this privillage to do. A report developer who has no access to universe by business process still this can be done by creating variables.For example we had a count in result dataset needs to be displayed with higher hierachy level, say state wise head count should be displayed to country level (result data set is ContryofOrigin,Region,InvoiceCount and BO Report should be [Country of Origin],[Inoice Count] ),To manage this in report level create a variable [Var.InoiceCount] has formulae =Sum([Inoice Count]). Now the Report uses this variable ([Country of Origin],[Var.InoiceCount]), This will work in report as you do in universe level

By: Dave Rathbun

Dave Rathbun — Tue, 07 Jul 2009 03:10:09 +0000

Thanks for the input, Andreas. You raise some good points.

Database delegated can certainly be an option, but isn’t available in earlier releases. And I would also suggest that the volume of data returned to the report also needs to be considered. Local calculations might be faster than rerunning a database query in cases of higher volume.