I am fairly new to OLAP and SSAS but seasoned in relational data wharehouses, and my question about Reference Dimensions is are they bad, a necessary evil, or useful when used correctly? Every single post I can find references Andventure Works and the Geography dimension, but I am looking for real world experience.
My cube has a date dimension that is pretty standard, and I want to create a date metrics REFERENCE dimension that has has a FK DateId to my Date Dimension. Inside of this Date Metrics reference dimension I will add a member for AccountId and several "Action" members to summarize specific actions that I want to count by date, month, or year etc.
At the root of it my date metric reference will be uniuqe on the DateID AND the AccountId which will enable me to summarize "action" movement by the date dimension I am trying to relate it back to.
Do I Have this all wrong?
Reference dimensions: means how you reference a dimension to a cube. When dimensions are created, they exist on they own, you add them to a cube on the "Dimension Usage" tab. This is necessary to be able to browse the cube's data using the dimension.
I think you are actually asking about "attribute relationship" (second tab on the dimension configuration), and the answer is they are extremely useful. I even saw a video once with a Microsoft MVP and he was saying that its probably the most important configuration you can do on your cube.
The attribute relationship indicate how the attributes on a dimension relate among themselves. So, for example, on a date dimension you will have
day -> month -> quarter -> year
its always the "opposite" configuration as if it were an hierarchy.
Another very important configuration is the relation type, which in the date example, you should set it to rigid, because the data will never change (the 01-01-2012 member will always belong to the 2012 year) so SSAS will maintain the calculated aggregations when you process the cube (unless, of couse, you do a full processing)
Related
We have a Tabular model with several Fact tables and several Dim tables.
We would like to manages roles so that specific roles will not be able to see members of a certain attribute within a dimension.
So in an HR cube with a "Work Hour" measure - i would like to block a specific role from seeing the "Employee Name" attribute but still show the sum of "Work Hours" to the total employee.
While using multidimensional, i simply used an MDX expression which filters on the "All" member of the dimension thus showing the total but not the members of an attribute.
Don't know how to do so in Tabular Model.
Did someone encounter a similar request?
Thank you!
Yes, Tabular models don't give you the option of disabling "visual totals". So this isn't easy to do. However if you get creative you can do it. If you remember that calculated columns are calculated at processing time without security then you can store the rollups you need ahead of time. Store those rollups somewhere users can read them from even with security in effect. In this case you may need to put the rollups in a separate table, separate from the employees since all rows in that table will be hidden. Here is a full write up:
http://cathydumas.com/2012/05/19/row-security-and-hierarchiespart-1/
However in your case since you want to hide all Employee table rows that will cause all related fact table rows to disappear due to security. So here is what I would suggest. First, disable the relationship to the Employee table. Second, pattern your measures after this pattern:
Work Hours := IF(
COUNTROWS(Employee)>0,
CALCULATE(
SUM(FactHours[Work Hours]),
USERELATIONSHIP(FactHours[EmployeeKey], Employee[EmployeeKey])
),
SUM(FactHours[Work Hours])
)
The logic here is that if your user can't see any employees then don't enable that relationship. If your user can see employees, then enable the relationship.
I have a problem in my SSAS cube:
There are two fact tables: OrderFact and PaymentFact, when I filter a date, I want to see payments related to filtered date orders. I designed a cube as follows, but I don’t get the desired result, can anyone help me out of this:
You will need to setup a many-to-many Date dimension. Basically you will have two measure groups in the cube. Then on the PaymentFact measure group you will go to the Dimension Usage tab of the cube designer and setup DateDim as a many-to-many relationship type using OrderFact as the intermediate measure group.
For more background about many-to-many dimensions in SSAS, I would highly recommend this whitepaper:
http://www.sqlbi.com/articles/many2many/
The other option is to copy DateKey to PaymentFact in your ETL then make it a regular relationship. If a Payment only relates to one order, then that's feasible. If a payment relates to multiple orders, then use the many-to-many relationship.
I have three tables, one fact and two dimensions. I want to make a referenced relationship between the fact table(measures) called InternetSales and the Geography table, se image(schemaCubeStructure".
The intermediate table is Customer. I first create the Geography and InternetSales tables and then the Customer with a field from Geography to use later when creating the ref. rel.
Everything works fine until browsing the data in the cube (se image "errorBrowseSalesCube". If i don´t make the relationship between the two tables i get image "correctBrowseSalesCube" which is what i want. That is i don´t get any data when processing with the rel.ref.
See image "dimensionUsageSalesCube for rel.ref.
Why is that i don´t get any data?
correctBrowseSalesCube
errorBrowseSalesCube
dimensionUsageSalesCube
schemaCubeStructure
What fields did you use when setting up your reference dimension relationship between Georgaphy and Internet Sales?
The in the AdventureWorksDW database, the Georgaphy dimension is a snowflake off of Customer dimension. In the AdvWrks cube project, Microsoft includes the geography table and corresponding attributes in the customer ssas dimension (red boxes in screenshot below). However, they could have, as it looks like you are trying to do, simply added the GeographyKey to the customer dimension (red arrow in screenshot below)
This exposes the GeorgaphyKey field when creating the reference dimension relationship so that you can properly define the relationship between the intermediate dimension (customer) and the reference dimension (geography):
After that, you can properly browse the Internet Sales facts by Georgraphy dimension attribute (and user) hierarchies:
The correctBrowse sales cube can be easily explained. It means that the data is not calculated based on the Geography dimension and thus indicates that the connection between the Internet sales and the Geography is not correctly calculated.
I would suggest the following:
Try making the customer a Mesaure (or fact table). Do not rename it just make a measure i.e. the count of customers (can be used as a counter of customers/per region or can be invisible altogether).
Then The customer will appear as a measure in Dimension usage and then connect Geography to Internet sales via a many to many relation Using the customer measure table.
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.
Why is it not necessary to define a hierarchy using the Date attribute from a date/time table?
The Analysis Service project seems to want me to create a hierarchy within my Dimension -- the tooltip says "Create hierarchies in non-parent child dimensions". I really had none that came to mind, so I tried adding a the PK Date attribute from my Time table, and creating a hierarchy with that.
When I do this, I get the error "Errors in the high-level relational engine. The 'dbo_Orders' table that is required for a join cannot be reached based on the relationships in the data source view."
I noticed in the AdventureWorks sample never uses Date in a hierarchy. Why is this?