How big is too big for BO XI 3.1 Unviverse

building semantic layer
1

I support a universe that is in size10Mb in size. Our team has made several suggestions to split the universe into several versions, but the users keep rejecting the advise.

Does anyone have any suggestions/recommendations? We are wondering if there are limits or best practices for universe sizing?

358 classes
14293 objects
8 conditions
227 tables
455 alias
527 joins
40 contexts
2 hierarchies

tkline :us: (BOB member since 2009-10-08)

2

Are you encountering any issues because of the universe size? If not, then leave it alone. :slight_smile: Smaller universes can be less confusing to users, and will also load faster (into the query panel). But large universes are not “wrong” just because they’re large. Here are the statistics of the largest universe I currently maintain:

The worst part of this universe is editing some of the LOV queries takes a very long time, but the users never see that. The above universe is about 20MB.

Dave Rathbun :us: (BOB member since 2002-06-06)

3

Hi Dave,

No hidden secret, but nonetheless felt like saying it. You and the BOB team has contributed so much to the whole bobj community. Thank you all so very much!

thanabhavan (BOB member since 2010-10-07)

4

Thanks Dave, We will do that.

tkline :us: (BOB member since 2009-10-08)

5

:shock: :!:

joepeters :us: (BOB member since 2002-08-29)

6

@joepeters, I was wondering if someone was going to pick up on that. :slight_smile: That’s not a typo, it’s a particularly large implementation of the time-slice solution that is detailed on my blog. There is one context per time slice (such as Period to Date or Quarter to Date) per fact table. This particular universe has 67 time slices and 25 fact tables. Not every fact uses every time slice, so the total number of contexts is lower than 67 * 25 but it’s way up there.

And no, I did not create them by hand. I wrote a VBA script to maintain the time slices in this particular universe. I am not looking forward to when we convert to the UNX format, as the utility will no longer work… :frowning:

Dave Rathbun :us: (BOB member since 2002-06-06)

7

I kinda figured you did. If you had to do it by hand, you’d still be working on it :slight_smile:

Is there any scripting for .unx? Can they be manipulated via the Java SDK?

joepeters :us: (BOB member since 2002-08-29)

8

@Dave and @SAP:
It would just be AWESOME if WebIntelligence offered such Time slicing out-of-the-box instead.

Andreas :de: (BOB member since 2002-06-20)

9

As it stands today, the Information Design Tool (ITD) does not have an SDK.

Dave Rathbun :us: (BOB member since 2002-06-06)

10

Oh…that is an awesome suggestion!!!

:cookie:

Eileen King :us: (BOB member since 2002-07-10)

11

The big challenge for “automatic support” would be to work with custom calendars, or custom time frames. We have time frames like YAG YTD LFW and YAG YTD LFP. The first is “year ago” or last year, year-to-date through the last full week, meaning it ignores the current (presumed partial) week. The next is year ago year-to-date but only through the last full period, ignoring the currently open and presumed partial current period. Then there are the rolling 4 week, rolling 12 week, rolling 13 periods… there are 67 different time slices in this particular universe. Not all of them are applied to every fact, and not all of them appear for all three years. For example, CY LFW is the current year last full week, which makes sense. We also have YAG FULL CW or last year full current week. There is no CY FULL CW because the current week isn’t done yet. :slight_smile:

Dave Rathbun :us: (BOB member since 2002-06-06)

12

Well, regular calendars would be a start!

Andreas :de: (BOB member since 2002-06-20)