I wanted to use dimension properties on columns. So, in the mdx query, I dragged in those properties from the dimension "member properties". But, for some reason, the values for those properties are nulls only. However, if the dimension members are used on rows, they have legitimate values.
Is there any other way, I can pull in those dimension values on columns?
You're not very specific about which properties you want to bring back, but you can always pull back more properties by adding this to you MDX query (assuming this is how you are querying, as it seems you are using a drag and drop editor):
SELECT {[YourDimension]} DIMENSION PROPERTIES KEY0,MEMBER_CAPTION ON COLUMNS
Related
I have two data providers. One is a universe, one is an excel file. Excel file has column ID. I want to find ID,JOB_ID, Cost
I have created a merged dimension:- ID. When I create report with ID and Cost, I'm getting an outer joined result which is what I want. But when I add another attribute from universe it is being inner joined result. Where can I control this feature
You are ever so close. Here are the basics when working with a zero or one to many relationships. Credit for this goes to this blog post. I am copying it here if perchance that link goes dead.
As a rule of thumb , when trying to merge DP’s with a 1xN relationship
:
Merge the common fields
Use the dimension coming from the N side query
Create detail variables from the 1 side query for each dimension needed with associated dimension equal the merged dimension
Check "Show rows with empty dimension values" on Table formatting for each table using dimensions coming from both queries.
Here is a screen shot to highlight where to find the setting in step #4.
We have an SSAS OLAP cube with some dimensions defined as
KeyNotFound -> IgnoreError and
KeyErrorAction -> ConvertToUnknown
One of this dimensions (and only one) doesn't work as expected, when the fact table value is not found on the dimension the values are not considered.
In other words, this particular dimension acts as if it were defined as
KeyErrorAction->DiscardRecord
Looking at the detail log of the building process it's clear that the behaviour must be this one, as the select looks like (simplified)
Select fields_from_fact_table,dim_key
from fact_table,dim_table
where fact_table.value_key=dim_table.dim_key
A join like this one only returns records present on the dim_table and this is the reason we cannot see the non-existent values.
But we cannot see any reason why this occurs. Why this specific dimension and not another one? Using a join with a dimension defined as DiscardRecord would be logical (yes, there are some dimensions that could be choosed on our cube) but using one defined as ConvertToUnknown just defeats the declaration itself.
The only reason we can imagine is that this particular dimension is used as the intermediate dimension of another "referenced" dimension (unsure of the correct name in English, it's the case when the fact_table links to a dimension and this one to a second one).
If this was the case SSAS should warn with an error when you select the ConvertToUnknown method.
A diferent fact_table with diferent dimensions, uses also a join (no referenced dimensions here), so it seems a join is always used.
Any idea about what is happening? How can we make this dimension work as expected?
Wow! Discovered the reason by accident. This specific Dimension is used as an intermediate dimension for another one. In this situations you cannot have null values.
I am a newbie to SSAS OLAP Cube. I need to create 3 measures from a single table column. Here is the table,
So, I have created 3 tables using Named query in Datasource View. But, it restricts to create 3 measure group for 3 measures. Is there any easy way to do this.
Without knowing how much access you have to create views on the database from which this cube is being created there are a couple of ways to do this.
Option 1 - In the Database
It is good practice to put a view over the tables that you want to build your cube against and point the cube to these views instead of the underlying database tables. If you create a view over this table you can create three columns in your view against the column you have specified above. In your data source view you will then use the view in the database instead of the table and as this view has all three columns they will be available to you to place in one measure group.
This would mean that your view will need to do the WHERE clause filtering and pivoting of the data.
Option 2 - In the Data Source View
If you cannot create a view in the database then you can create all three columns in one named query and thus have one object in the data source view that contains all three columns. This will then allow you to use those columns as measures in the same way that the view in Option 1 would have allowed.
Option 3 - Calculated Measures from three DSV objects
You could keep your solution exactly as it currently is and have three measure groups, each with one measure in them. You then set each of these measure to be Hidden, which will hide the measure groups from users. You then create three calculated measure in SSAS each pointing to one of these measure and set the display folder of all three calculated measures to be the same. When a user then connects to your cube they will see only the calculated measures and they will all appear in the same folder giving the appearance of being in the same measure group.
Option 4 - Calculated Measures using Dimension Filtering
If the value you are filtering on in your where clause in the DSV is brought into the cube in a dimension then you could instead create only one measure from the named query you have created. You can then create three calculated measures and in the MDX of each you will refer to the measure in your measure group and filter based on the Dimension attribute and its member values. You can then place these calculated measures in your measure group and set the original measure to be Hidden.
Option 5 - Filter by the dimension attribute
If you have a dimension with TxType in it you could set the Aggregation function of the measure to Count and then simply drag the TxType attribute from the dimension where it is located onto your reports to filter the measure according to its members.
I hope that helps.
I have a cube with 3 fact tables and 20 + dimensions that relate easily to all 3 fact tables and everything works fine except for the fact that one of the dimensions (Warehouse) is only related to 2 of the 3 fact tables. My problem I guess is a display issue. When the user is viewing measures from all 3 fact tables then drags over the Warehouse dimension, it simply repeats the grand total of the measure in the 3rd fact table for every possible value of Warehouse. This certainly makes sense to me as there is no relationship set up and it's conceptually behaving almost like a cross-join. Nonetheless, it's confusing to users and I'd like to not have the grand total duplicated for each dimension member in Warehouse. I was thinking one solution was to create a dummy warehouse called "Not Applicable" and then relate every row in the 3rd fact table to that dimension member. I was hoping there's just a setting in SSAS where I could control this behavior so I didn't have to create any new warehouse values. Is there a standard way to handle non-related dimensions with multiple fact tables? Thanks in advance.
You can use the "IgnoreUnrelatedDimensions" property of the measure group not related to Warehouse: set it from the default value true to false. Then, measure values for this measure group will only be shown for the "All" members from the warehouse dimension, and the cells will be null (empty) for non-All members of this dimension.
This is a global setting per measure group, you cannot configure it individually per dimension and measure group. But for your purpose, this should be fine.
I was hoping someone could explain the appropriate use of the 'FACT Relationship Type' under the Dimension Usage tab. Is it simply to create a dimension out of your fact table to access attribute on the fact table itself?
Thanks in advance!
Yes, if your fact table has attributes that you would like to slice by (create a dimension from), you would use this relationship type.
Functionally, to the users it behaves no differently than a regular relationship.
After you create your dimensions and cubes you need to define how each dimension is related to each measure group. A measure group is a set of measures exposed by a single fact table.
Each cube can contain multiple fact tables and multiple dimensions. However, not every dimension will be related to every fact table.
To define relationships right click the cube in BIDS and choose open; then navigate to the Dimension Usage tab. If you click the ellipsis button next to each dimension you will see a screen that allows you to change dimension usage for a particular measure group. You can choose from the following options:
Regular default option; the dimension is joined directly to the fact table
No relationship the dimension is not related to the current measure group
Fact the dimension and fact are derived from a single table. If this is the case your dimensional warehouse has poor design and isn't likely to perform well. Consider separating fact and dimension tables.
Referenced the dimension is joined to an intermediate table prior to being joined to the fact table. Referenced relationship resembles a snowflake dimension, but is slightly different. Suppose you have a customer dimension and a sales fact; you'd like to examine total sales by customer, but you also want to examine line item sales by customer. Instead of duplicating the customer key in the line item fact table you can treat the sales fact as an intermediate table to join customer to line item.
Many-to-many this option involves two fact tables and two dimension tables. Dimension A is joined to an intermediate fact A, which in turn joins to dimension B to which the fact B is joined. Much like with fact option if you need to use many-to-many option your design could probably use some improvement. This type of relationship is sometimes necessary if you are building cubes on top of a relational database that is in 3rd normal form. It is strongly advisable to use a dimensional model with star schema for all cubes. For example you could have two fact tables: vehicles and options; each vehicle can come with a number of options. You're likely to examine vehicle sales by customer, and options by the items that are included in each option. Therefore you would have a customer dimension and item dimension. You could also want to examine vehicles sales by included item. If so the vehicle fact would be joined to the options fact and customer dimension; the options fact would also join to items' dimension.
Data mining target dimension is based on a mining model which is built from a source dimension. Both source dimension and target dimension must be included in the cube.