Saturday, October 31, 2009

IsAncestor explanation

Recently I answered a post on the user forum regarding a way to test if a member is a Descendent of another member using MDX member formula's in an ASO database. It took me a little while to figure it out. I think it's a little hard for Essbase people to understand because of the way we used to do it in BSO using the function @ISDESC. Below was my response and I thought it was worth posting on the blog.

--In calc script language you are saying @ISDESC("C009") meaning you want hierarchical members below "C2009". Now in Calc script we also have @ISANCEST and if we said @ISANCEST("C009") we would be looking for all members that are hierarchically above "C2009". MDX does not have ISDESC, MDX only has IsAncestor. The parameters are member1 and member2. Now depending on which way you ask the question, you get a different answer.
IsAncestor([C009], [Dimension].CurrentMember) is really saying "Is "C009" an ancestor of the current member"? The answer is only true for descendants of "C009". Now, if you were to say IsAncestor([Dimension].CurrentMember, [C009]) you would be asking "is the current member an ancestor of "C009""? The answer is only true for ancestors of C009.

Book Review: Oracle Essbase 9 Implementation Guide

A while back, I was asked to do a book review for Oracle Essbase 9 Implementation Guide by Sarma Anantapantula and Joseph Gomez by the publisher, Packt Publishing. Despite terrible flashbacks of grade school book reports, I agreed and was shipped a copy of the book. When I first heard this book existed, I rolled my eyes and thought, “this probably won’t be very good”. Then I thought about it a bit, gave some thought to what goes into writing a book, and realized I was being unfair to prejudge. Despite the fact there has historically been very little published content on Essbase, maybe these people got it right and as an active member of the Essbase community, I should embrace the idea of our little world getting more notoriety. It was with this open mind that I began reading the book and hoped to write a positive review.

As I began reading the book, I was encouraged by what I saw. Aside from some minor misstatements in the preface (things like products called ‘Essbase Planning’ and ‘Hyperion Smart Office’) the opening was very good. The authors had an excellent segment defining a data warehouse, frankly, it was one of the best explanations I’ve read on a term that is extremely over used by people to describe many things that are not in fact data warehouses. After reading the preface, I thought to myself “this book is on the right track”. I even made a point of commenting early on that I thought it was a “pretty good book” on a user forum post on Network54. Unfortunately, as I continued to read, I became less and less impressed with the book and about half way through started to feel the book was not what I thought and hoped it would be.

I’m not one of those developers who has a book memory, when working with Essbase I always have a copy of the technical reference and database administrators guide close by, so I’m not going to dive into the technical inaccuracies in the book, although I believe there were many. For the most part, I was not comfortable with the way the book was written. The authors tended to speak very authoritatively about topics that are not absolute. “Essbase is more art than science” is a term repeated ad nauseam in the book, yet the authors took the position in many instances to speak in definitive statements without clarifying what they were saying. Statements like “While the dynamically calculated member occupies a place in the database outline, it does not affect the block size in the database, therefore, it does not affect performance”. They do not clarify what kind of performance they are talking about. Dynamically calculated members with member formulas referencing sparse member sets, most definitely have a performance impact. Referencing dynamically calculated members within a calculation script can also impact performance by engaging the dynamic calculator cache. I realize the book is for beginners and maybe these topics are not appropriate early on in the book, but they needed to be careful making such declarative statements, which they did quite often.

Much of the material in the book can be found in the database administrators’ guide, which has a more thorough explanation. I can accept that in a book of this nature because you would expect the product’s documentation would have all the technical content. What you are looking for in a book like this is the author’s particular point of view and words of wisdom to help understand the technical content. Often I felt the author’s viewpoints were very specific to their own experiences and the book seemed narrow. It was clear that industry experts had not proof read any of the chapters. At the end of the day, you have a book written by a couple of guys who have used Essbase for a while and decided to write a book about it. I don’t say that to take anything away from the effort they put into it, only that it doesn’t have the breadth of experience needed to make it useful to individuals learning how to use this product. The authors often created their own terminology and expressed it as accepted industry jargon. They presented concepts that many would not consider best practices, such as using aliases as the permanent name for a member and codes as the alias. The example given was something along the lines of having a member name as “Hood Esscar Best Dealers” and using an alias for the dealer ID ‘03030-USA’ They then state how you could change the member name and still load to the dealer ID because it is the alias. While this is technically correct, best practice in my experience would be to have the dealer ID as the member name and the name as the description (i.e. Alias). This is an example where I think, in their experience this is the way things are done, but it is not really the best practice.

There are many other examples of things I found to be inaccurate or misleading at best. I won’t get into all of them. Overall, the book was just not written very well, there are many cases when the context of a section will shift direction and it is not clear why, at times, I felt as if someone had accidently cut a paragraph out of the book. This leads me to my primary criticism of the book. The feeling I get was that the book was rushed. The quality was not good and in many cases, it affected the message the authors were trying to get across. This seemed very strange to me that the book would feel rushed because initially I thought it was odd that the book was based on Essbase 9, when Essbase 11 was already general release. I didn’t take this too much to heart because I knew from the Kaleidoscope conference that a large number of users were still on version 9. What I realized as I read was that while technically it was based on 9, often things the authors claimed were based on early releases of version 9, particularly the section on ASO, which was extremely disappointing. It was clear the author’s experience was almost entirely block storage and the feeling I got was that the bulk of what they talked about was relevant in version 6, not so much the newer functionality we have today, with the exception of their discussions on EAS.

Overall, I was not left with a good impression of the book. I would caution new users reading the book to be careful applying what they have learned at face value. While there are some good parts to the book, I found more about it I didn’t like.