Microsoft and R?

I've read here that Microsoft had acquired evolution Analytics, the company who provide open source distributions of R, alongside commercial “Enterprise” extensions for big data infrastructures.
Since I've decided to broaden my skills set lately by learning R, I believe these are exciting news for the following reasons. The writer of the post, Tony Davis, mentions that it must be to replace/extend SSRS; learning it for a short while, I believe that on top of SSRS, you can use R functionality for acquiring data, modeling, data mining and reporting. Essentially: everything BI, or SSIS, SSAS and SSRS.. Since R reads all the data into RAM, it can also replace/extend the in memory OLAP which exists nowadays in SQL Server 2012 (or the Tabular Model).
Another thing which is important to point out for the SQL developer who's keen to learn R, is the "thinking" of the language. As an SQL developer (especially MS, not necessarily Oracle), we're used to think in "Sets". We don't go row-by-row when we write code, but instead it's table-by-table. It was a type of thinking which is hard to get used to (it was difficult to learn normalization). And then when you need to learn BI, you had to "unlearn" the normalization part, but you're still going by rows. Writing code for regular programming languages (like C, Java, whatever) requires you to go row-by-row, one data (structure) after the other. 
In R you have to go row-by-row, while you could still query after a set of data. It requires a completely different type of thinking; if you tell me "data set", I immediately think "SELECT FROM WHERE". It doesn't work this way in R (though you could implement this type of syntax in R). So not only you can have many uses of R, but if might even use R instead of writing a cursor. 

So essentially I believe that Microsoft had purchased R in order to extend SQL in many good ways. Either way it makes sense to take the time and learn it!

Dimension Relationship in a Recursive Hierarchy

I'm now working on a data warehouse project with SSAS 2008 R2 (Sql Server Analysis Services). It is very refreshing to do something different after doing MS-Access for so long.

While designing the dimensions in Analysis Services I had the following problem: working in a Financial Company, every client has a client group. Sometimes it is the same client group as the client, and sometimes it isn't. Pretty classic material:
John & Jane Smith (account id: 1) and John Smith (account id 2) both belong to the same "client group" of John & Jane Smith. So far nothing special: the dimClient table has a self referencing attribute to dimClient with the id of dimClientGroupId.  The problem arises when I need to group by properties of the client group, and not by the client itself. Sometimes the adviser for "dimClient" is different then the adviser of "dimClientGroup", and the business needs to view the data by the Client Group, and not by the Client.
So I have quariable attributes that are different in different parent-child levels and I need to present the data properly. I tried using the "client group adviser" as an attribute to the client but it didn't work. It also didn't group the data correctly.

So, how do I use the attributes of the parent dimension in a self-referencing dimension?(Please note: using "self referencing" is better than "parent-child", because then you get to all sort of parenting material; useful, but not what I'm looking for right now!)

Generally, it is advised against using too many parent-child hierarchies in Analysis Services, unless "there's a genuine business requirement" (which happens to be the case).

So, after designing all the dimensions I had to link the "adviser" dimension to the "client" dimension. That was easy (and maybe even done automatically) as every client has an adviser. Now I had to link the "adviser" dimension to the "client group" dimension and this is where I got stuck (after all, "client group" is a self-referencing dimension and is treated by SSAS differently!).
My solution has two levels. I might change between them in the future, as there are no guarantees that my first level will continue to work.

Using "referenced dimensions" I linked the "adviser" dimension to "client".
Now, I've linked the "client" dimension to "client" again and - voila! - I have the "client group" dimension and I can view in the cube the "client group.adviser" dimension and filter by it. A warning: trying to deploy the cube generates an error: "Errors in the metadata manager. The 'Dim Client Group Id' intermediate granularity attribute of the 'Dim Client' measure group dimension does not have an attribute hierarchy enabled.". Nevertheless the cube can still be processed and view from the SSMS - Analysis services, and the numbers are correct.
There is a different solutions to the same problem that is suggested in here (under the "parent-child Hierarchies" short section):
As the numbers of Hierarchies in this business model is fixed (every client has one and only one client group), Creating a bridge table of "portfolio client" which includes only the client and the client group (both are foreign keys to the "dim client" table) and again, using it as a reference dimension as follwos:
[fact]portfoio -> [dim]portfolio client ->[dim] Client Group ->[dim]Adviser sorts this problem in an even clearer manner and without ugly error messages. A good explanation about bridge table could be found in here (they bought me with the term "Graph Theory").

MdxScript(DB) (8, 5) Parser: The syntax for ',' is incorrect

This problem appeared all of a sudden out of the blue in my Cube, while trying to calculate a new member. I usually create a calculated new member using the "Calculate" sub-tab in the toolbar of the "Cube" Tab in SSAS (2008 R2).
The Solution is to go to "Script View" in the toolbar and this is what I saw there:


CREATE MEMBER CURRENTCUBE.[Measures].[Calculated Member]
 AS ,
VISIBLE = 1  ;   




With a red squiggly line under the "AS ,", as it did need a name.
Deleting those messy rows helped, as well as re creating the Calculated Members that I've needed.
Apparently, I was trying to create a new "calculated member" more than once and one of them wasn't edited. As I had quite a few (more than 10) I didn't even notice.
So while using the SSAS MDX features knowing actually how to write MDX is a useful feature even for beginners such as myself.