Applied dimensionality

Okay, it has been almost half-a-year (oh, dears) since the last decent post on this blog. Russian one has suffered as well, I must note.

Reasons vary, but mostly it's that I've been, you know, busy-busy. As I now start to reflect on it, it's always a point of view thing and a question of self-control and ability to say no )

But enough philosphy, brief recap on what happend while I was out "there" in real world. I'll divide this into two parts (by vendors ))

Continue Reading »

Just a quick tip: read this cognoise thread thoroughly -- really in-depth discussion.

Go check the download page.
One wonders, what's that 64-bit BI server is all about -- they've really pushed the report server further, or that's just compatability release.

We've encountered an annoying Cognos 8 bug recently. 

Usual scenario if you're creating reports over Enterprise Planning data includes "unioning" data from several applications. 

For example, you have an Operating Expenditures planning application and a Sales Planning application. To make a simple P&L, you just have to show up data from both these applications. So you can either:
Continue Reading »

Read Edward Roske and Tracy McMullen's "Look Smarter than you are with Essbase System 9" over the weekend. It's really the best "technical" book I've read over past couple of years. Written in simple and not annoying language, with a lot of humor (I couldn't hold myself when I've read the fight club joke) -- definitely a must-have book for any essbaser out there. Found really helpful, although I knew most of the points already. But, oh my, appendixes rock -- calculator cache explained is a real gift.

And, more important, this book really gives you an overall picture and shows a way to go. DBAG covers every topic with excessive amount of details so you can't see the forest over the trees.

Kudos to Edward and Tracy, it's a fantastic job. I'm waiting for ASO one.

PS: Too bad it wasn't there a year ago. And too bad there are no such books on cognos
PPS: Edward has a blog, as you all know.

Why am I writing this?

Well, sometime it helped and we now have allocation tables in administration links. Although I'm sure my post didn't have any impact, some deem hope remains

I'm going to repost this into Communities and into Insight. And, maybe, we can create some noise by voting for these enchancements in Insight aka registering those enchancements again (they get piled up together, as I've found out).

Some those two echs are:

1) Easy as: "Add the ability to import Calculation Options and Weighting while importing a dlist"

If you've ever done some external dimension management, you know that:

- you have to use unique names to keep dlist IID the same when names (but not unique codes) of items change

- you can import formulas as calculation text, just put item names in curly brackets )

- if you use Update\Remove obsolete it always deletes all Calc Options and Weighting from dlist. That means that you cannot update any cacluation dimensions, such as Accounts. 

So you manage all simlple dimensions by updating them (with Remove Obsolete selected) and unique names, and you manage all dimensions with weighting by manually changing them. 

Shouldn't be like that.

2) Even simpler: Add a Contributor macro for importing translations

It seems weird to have a single table with translations for Cognos BI and then to manually (or semi-automatically by text import) copy it into Contirbutor application. Shouldn't be hard, ability to import translation text is already there, just need a macro step

3) And another one (maybe no one will notice): Import deployment packages as a macro step too  

Automating dev-prod. backup-restore -- all those things that should be automagical

So, if these things annoy you as well -- drop me a line, and I'll send you Cognos Insight ench numbers to vote for.

Finally got a chance to try essbase out on real data volumes. Building half-a-billion facts cube turned out into something like this:

PS: I have very special attitude to David Lynch's films. A physical one. Just the sight of road running away at "Lost Highway" makes me creepy. It takes me about 5 seconds to identify Lynch's work, as I've found out while watching "Chacun son cinema". Might be camera angle...

With so-long waited new Contributor client, with expand\collapse and nest dimensions features. And a lot, lot more. ActiveX free ) Actually, as long as I'm with cognos ep (since adaytum 2.4), contributor was always the same good-old-rigid tool, so it's a revolution indeed.

Well, with a huge lot of bugs inside, it's time, gentlemen, to power up virtual machines and start testing it all over. We need to log on maximum of bugs before sp1.

New enterprise planning goes under Cognos 8.4 (BI version was out a month earlier), and this minor number increase doesn't reflect the amount of changes. They'd better start it of with 9.0 it seems.

I'm not dead, just trying to push it through to my vacation. Lot's of small news, like 'I've attached cognos to essbase cubes and they work together like charm, I'm impressed', but no time to write it out.

Anyway. I'll be spending next couple of weeks in Europe, so if you want to share a beer -- drop a line.
I'll be starting 29.07 in Amsterdam with no set programm afterwards (although Berlin seems a definite place-to-go).

I already wrote some notes on choosing dimension for publish in this post.

Today I just want to add some of points:

1 If you're up to publishing some serious amount of data, variant with adding a dummy dlist with 1 item and using it as dimension for publish seems a very bad idea.  You're terribly slowing proccessing and wasting tablespace. So you have to choose a dimension for publish to reduce table size and speed things up

2 Dimension for publish must be:

a Stable. It shouldn't change or change very rarely, since these changes will cause Framework Manager models \ ETL models changes.
b Have sane (~3-33) number of elements. If less than 3, there's no win in performance. If more than 30, ensure it won't change, because big dimensions change more often than small ones.

3 There are dlists that are naturally stable aka measures, like {Quantity;Price;Sales}

4 In other cases timescale seems a really good choice. For example, if months dimension doesn't have year signs in name (like Jan, Feb, Mar), columns in publish won't change ever.  To work with timescale published data you can use sql unpivot queries, that will virtually turn it into view publish, but it'll way more effective than publishing it by 1elem dimension in first place. I've settled for this variant in my current project. Moreover, if you wrap this unpivot sql into ETL procedure, you can treat all published data uniformly while loading into datamarts (publish all needed cubes on timescale, use the same etl procedure).