Dimension is made with collection of key column attributes so:
...
hierarchylevel2key = level2attribute + level1attribute
hierarchylevel1key = level1attribute
...
Hierarchy has many levels, so in the lowest levels of the hierarchy, the key combinations are quite complex:
[Dim].[Hierarchy].[level1].&[level2]&[level3]&[level4]&[level5]&[level6]&[level7]
Now if i want to make a generic named set for level5 members, it's in MDX:
[Dimension].[Hierarchy].[level5].members.item(2)
and it returns the second member of the level5, but because the hierarchy is ragged (?) sometimes this item(2) does not exist.
.
Do i have to make gazillion of different named sets and manually have to pick the right existing items for the sets?
Or alternatively have i made mistake building the dimension hierarchy this way ?
Related
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 have a Dimensional table structure which resembles the following:
Ideally the hierarchial representation should be
CodeClassDesc --> CodeDesc
So A would be a Parent to A and B; B would be a Parent to A, B and C in my Analysis Server Cube. The problem is that because CodeClassDesc has multiple entries in the table it produces multiple duplicate Parents in my Cube with a single corresponding Child Element per Parent which is not what I'd consider a true Hierarchy. Or at least not what I am looking for the expected results.
I believe this is possible in SSAS without having to manipulate the data within the table via a VIEW but I don't know what I'm missing.
I've tried defining the CodeClassDesc and CodeDesc fields as a composite key but that doesn't work, yet I am almost certain there is a way to do this.
After attempting every conceivable permutation of methods to acquire resolution for this, I concluded that normalization of the required attribute was the only way to resolve the issue of having multiple entries of the Parent for every corresponding Child element.
So I created a VIEW of the table using a DISTINCT SELECT of only the CodeClass and CodeClassDesc fields in my DSV (DataSource View) in the Cube. Then I set the CodeClass field as a logical Primary Key and created a relationship between it and the CodeClass field of the main table.
I then used the CodeClassDesc field of the VIEW to create the top-level parent in my Dimension, which gave me only 1 distinct record for each value; and added the CodeDesc fields from the Table to create the Child Relationships. Works like a charm so I guess the answer would have to be that you cannot create a Parent Hierarchy consisting of a single Value per Parent if the source has multiple records.
In the dimension structure, you should change the property KeyColumn of the attribute "CodeClassDesc" to a composite key containing both "CodeClassDesc" and "CodeDesc" then change the NameColumn property to show itself
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.
I new to OLAP, and still not sure how to create a relationship between 2 or more entities.
I am basing my cube on views. For simplicity sake let's call them like this:
viewParent (ParentID PK)
viewChild (ChildID PK, ParentID FK)
these views have more fields, but they're not important for this question.
in my data source, i defined a relationship between viewParent and viewChild using ParentID for the link.
As for measures, i was forced to create separate measures for Parent and Child.
in my MDX query however, the relationship does not seem to be enforced. If i select record count for parent, child, and add some filters for the parent, the child count is not reflecting it..
SELECT {
[Measures].[ParentCount],[Measures].[ChildCount]
} ON COLUMNS
FROM [Cube]
WHERE {
(
{[Time].[Month].&[2011-06-01T00:00:00]}
,{[SomeDimension].&[Foo]}
)
}
the selected ParentCount is correct, but ChildCount is not affected by any of the filters (because they are parent filters). However, since i defined a relationship, how can i take advantage of that to filter children by parent using a WHERE clause?
Facts:
viewParent, viewChild
Dimensions:
ParentDimension (contains attributes from parent view that i'd aggregate on)
ChildDimension (contains attributes from child view that i'd aggregate on)
This is just an idea i came up with, but maybe my design/relationship is off.
Figured it out.
Looking at the dimensions tab of the cube in vs2008 it became obvious.
my relationship between dimension and the measures was not set-up correctly. My dimension was keyed on uniqueID which corresponded to parentView uniqueID.
I changed the relationship (of SomeDimension) to key on a different ID field (shared by both parentView and childView) let's call it ViewID.
and my MDX queries started working as expected. Meaning, WHERE clause affected both measure groups: parent and child.
It may be that I am reading too closely into the wording you chose in your description, but you may want to clarify what you mean by filters. Technically the WHERE clause isn't a filter but instead identifies the slicer axis for the resulting data set. If you mean FILTER, then you may want to look into the MDX function named FILTER which you can apply to a set expression.
What you may try is rearranging your MDX query to define BOTH Axis - ROWS and COLUMNS.
SELECT
{
[Measures].[ParentCount],[Measures].[ChildCount]
} ON COLUMNS,
{
[SomeDimension].&[Foo]
} ON ROWS
FROM [Cube]
WHERE ([Time].[Month].&[2011-06-01T00:00:00])
I have designed a relatively simple data warehouse that uses the star schema. I have a fact table with just a primary key along with CompanyID and Amount (the actual measurement) columns. Of course I also have a dimension table to represent the companies which the fact table references.
Now I'm required to create a single level hierarchy (CompanyGroup) for companies. This seems like an easy task but the catch is that a single company should be allowed to exist within multiple CompanyGroups.
I experimented with this by creating a new dimension table called CompanyHierarchy that holds a primary key, GroupKey and CompanyKey. Defining a user defined hierarchy where GroupKey is the top level and CompanyKey is the second level yields A duplicate attribute key has been found error for the CompanyKey attribute while processing the dimension.
So, I'm not quite sure how to even start with this. How can I create a user defined hierarchy within a dimension where attributes can exist multiple times?
Screen shot of my current cube definition can be seen at:
img132.imageshack.us/img132/6729/ssasm2m.gif
You need to create a many-to-many relationship (one company can belong to many groups and one group can have many companies) There is an example of a many-to-many relationship in the Adventure Works cube around the sales reason dimension and there is an extensive white paper here that explains a number of different ways of using many-to-many relationships.
There is also a technique for supporting multiple members in the one hierarchy that I documented here