Let's say we have a Product dimension with three attributes:
ProductID (Key)
Color
Category
It seems each attribute has an All member.
Each All member is independent? I mean it is technically posible for the All member of Color attribute to have a diferent value than the All member of the Category attribute?
Is is possible to talk about the tuple (All "color", Winter category)?
The product dimension by itself has an All member?
I mean when talking about (2012 Year, Jan Month) when Year and Month belong to the Date dimension (diferent of Product dimension) I should think as if it was refering to:
(2012 Year, Jan Month, ProductID attribute All Member, Color attribute All member, Category attribute All member)
or
(2012 Year, Jan Month, Product dimension All Member)
?
EDIT: Maybe I should rewrite the question... I'm not sure at all how many "all member"'s exist in a given cube and how can I refer to each one of them.
I'm reading a book about SSAS 2008 R2. After some more Reading I think I should update the question, for instance when I'm refering to attributes I should say attribute hierarchies (no user defined).
Instead of answering my question, I would recommend anyone that feels lost trying to understand what the hell is a tuple, or cube spaces, mdx expressions, to read the book "Microsoft SQL Server 2008 MDX Step by Step"
Related
When making a date dimension in a SSAS multidimensional cube, it is simple to make a hierarchy and attribute relationships for day, month, quarter, and year, which all roll up into one another. But what if I have a couple of attributes that combine month and year, such as "Jan 2019" and "01/19"? I made these because I know the charts will use them. If I take one of these attributes called [Year Month] and place it as seen below where Date -> Year Month -> Quarter -> Year, then it gave me a warning that I create another hierarchy, which I did, but that seems not user friendly to have a few nearly identical hierarchies when they are browsing fields. Or should I have kept [Year Month] in an attribute relationship with Month Name, like I did with the other Month Year fields in that list?
If I don't add additional hierarchies, then I get a warning that says "Design hierarchies for each incoming relationship path when attributes have multiple incoming relationships or, if any of the incoming relationships are unnecessary, you should delete them."
In summary, I have a few attributes whose key value is the same (month/year)- how to approach this?
The warning (blue squiggly) is just saying to avoid visible attributes used in hierarchies. I will get around to fixing that once I solidify things.
After googling the warning message that I added into the question above, I discovered some posts/articles suggesting you really should add a hierarchy for each path or otherwise the "attribute decoding" won't work. I also think it does make sense to put Year Month on its own path (so the diagram is correct). And then I discovered you can make a hierarchy invisible to the end user. If you go to your cube and expand a dimension and then click on an individual hierarchy, there is a Visible property you can set to false.
However, I also decided to reduce these additional attributes of type string/varchar down to one after reading how it can hurt performance to have a lot of string attributes.
I am on an MDX adventure and I'm at a point where I need to ask some questions.
I have a very basic dimension named Car. The attributes which comprise Car are as follows-
-Manufacturer
-Make
-Color
-Year
My fact table contains a sales measure ([Measures].[Sales]). I would like to know , without explicitly defining a user hierarchy, how to sum the sales from
a specific group in this hierarchy
For example, I want to sum the sales of all red Trucks made in 2002. My attempt errors out-
sum([Cars].[Make].[Make].&[Truck]&[Red]&[2002], [Measures].[Sales])
How can I navigate the attribute hierarchy in this way? I will be browsing the cube in excel
Thanks
If you open an mdx query in SSMS and drag a member from one of your attribute hierarchies into the query pain you will see the full name.
You definitely cannot chain hierarchies like this ...].&[Truck]&[Red]&[2002]
Each full name will likely be similar to what MrHappyHead has detailed but usually the attribute name is repeated e.g. for Make:
[Cars].[Make].[Make].&[Truck]
MrHappyHead have wrapped it all in the Sum function but this is not required - just wrap the coordinates in braces and a tuple is then formed which will point to the required area of the cube:
(
[Cars].[Make].[Make].&[Truck],
[Cars].[Color].[Color].&[Red],
[Cars].[Year].[Year].&[2002],
[Measures].[sales]
)
note: square brackets are pretty standard in mdx.
Is it something like:
Sum(
Cars.make.&[truck],
Cars.color.&[red],
Cars.year.[2002],
Measures.sales
)
I have a SET of members of some dimension, let's say [Dim].[Dim].[Dim]. Then I wrote a query that returns all the elements from this dimension for 2016 year of some measure, let's say there are 5 of such.
The next step that I want to make is to find first one member in this dimension with the same name (as CurrentMember in row) but for 2015 year. As result, I want to calculate some measure with regards to 2015-member, not 2016's.
So the problem is in scope - I can't GENERATE such set because CurrentMember's function scope will be equal to GENERATE's scope so I am unable to extract actual current member that is on row now and for which I want to find "same previous by name" members.
Am I able to do this with plain MDX or should I go with some workaround like finding such "same" elements in t-sql view and making child-parent relations in cube by hand? The second approach I think is very undesirable and ugly.
Thanks.
Is there a reason you can't just use .PrevMember on the Time (Year, I guess) dimension?
WITH MEMBER [Measures].[SomePrevYearCalculation]
AS ([Time].[Year].CurrentMember.PrevMember,[Measures].[AMeasure])
SELECT
{[Measures].[AMeasure],[Measures].[Some2015Calculation]} ON 0,
[[Some complicated dimension stuff]] ON 1
FROM Cube
WHERE [Time].[Year].[2016]
Or are you dealing with a dimension that has multiple duplicate Names at leaf-level, so that you can't match the 2015 to 2016 figures by the actual dimension member?
I have built a small data warehouse using the Adventure works database. I have deployed it to SQL Studio Manager. I have written my first MDX query
select
customer.[full name].members on rows,
order (measures.[sales amount],asc) on columns
from [Adventure Works DW2012]
Please see the screenshot below:
I understand that the top level of the hierarchy are dimensions i.e. Customer, Date, Due Date, Interne Sales, Order Date, Product and Ship Date. I understand that dimensions have attributes. For example: Model Name, Product Line, Product Name are attributes of the Product dimension and Product Model Lines is a hierarchy of the Product dimension.
What is meant by: Financial; History and Stocking?
You've come up against something I think is a genuinely confusing and ill-designed aspect of SSAS.
You're correct that Model Name, Product Line and Product Name are attributes of the Product dimension. But what you're seeing here (in your screenshot) is hierarchies called Model Name, Product Line and Product Name.
These are not "hierarchies" in the sense that most people use the term (a structure with more than one level). They're the "attribute hierarchies" based on the attributes of the same name. They only have one level two levels. (EDIT: as whytheq pointed out, they have one leaf level, and almost always also have an "All" level).
(EDIT) Product Model Lines is a "real" (aka "user") hierarchy, with multiple levels apart from the All and leaf levels, based on multiple attributes.
Financial, History and Stocking are "folders". They get "created" by the setting of any AttributeHierarchyDisplayFolder property of any Attribute in the Dimension design (or the DisplayFolder property of any "real" hierarchy). They have nothing to do with any dimension structure - they're just for display convenience. Probably necessary because, as becomes clearer the more I try to explain it, the structure of Dimensions in SSAS is really unnecessarily complicated.
You can hide the "attribute hierarchies" from client applications (e.g. Excel) by setting the AttributeHierarchyVisible property of the attribute to False. But they'll still show up in the MDX "helper" screen you're looking at.
I am working on SQL Analysis service to provide ad hoc reporting in my application. I have created a time dimension to use in my cube. It has some predefined attributes. e.g. Month of year. It is having values like Month 1, Month 2, etc. while I want January for Month 1, February for Month 2, etc...
Can any one please suggest me some work around it??
As I am newbie to SSAS, Sorry if I am missing something very silly....
When you work with attributes in SSAS, there are two properties that affect the members of that attribute. The first property - which is set by default when you create the attribute - is KeyColumn. The column that you use here determines how many members are in the attribute because processing generates a SELECT DISTINCT statement based on this column. It's a good idea if you use an integer value here for better performance.
It sounds like perhaps you have a month number for your attribute here, which is good. Except that you want to display a month name. In that case, you set the NameColumn property with the column in your data source view that contains the month name. This produces the label that you see when you browse the dimension.
That said, it's usually not a good idea to have just a month number or month name because you probably want to create a hierarchy to roll up months by year and you won't be able to do that with just a month name. I wrote a blog post describing how to set up a date dimension that might help you: http://blog.datainspirations.com/2011/05/11/sqlu-ssas-week-dimension-design-101-2/