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.
Related
I have a DimPerson table and a DimPersonDecileOutrigger Table which stores decile data. The way the outrigger is structured is that a customer is given a decile for current year and previous year (if they have bought in the period)- which means a customer might have TY and NOT LY and vice versa. Some customers are both.
In ssis when I picked the columns in dimension structure- I initially only picked columns from DimPerson and not the outrigger. That way in the browser it showed all the id's starting from 1. But when I dragged some columns from outrigger- then in the browser it doesnt show all personID's. I want to see all customers regardless of them having a decile or not.
Pic attached to show what it looks like in dimension structure tab. Also the relationship is between OutriggerID as primary and OutriggerID in person as foreign.
If you just want to solve the problem, you can create a View in your underlying relational database that uses LEFT OUTER JOIN to link the two tables, so that the view will return all rows from DimPerson, even if they don't have a Decile.
Then use the view as the source for your dimension instead of the tables.
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 am modelling cube in SSAS. Cube has around 20 dimensions and 6 fact tables. Some of the dimensions are common among the fact tables. e.g. Time dimension. Fact_PNL has 3 date columns for those we have 3 role playing dimensions in the dimension usages.Another fact table has 5 date columns for them as well we have separate role playing dimensions in dimension usage tab. We have a common dimension Company which is foreign key in all fact tables. We might need to combine the data from multiple facts to get final output.
Should i create 6 role playing dimension for each of the fact table or use the same dimension for all fact tables?
Role playing dimensions should be created when we have multiple columns pointing to the same dimension ?
It's up to you. If the role playing dimension plays the same logical role for each fact table, then I would use the same RPD for the same logical role in each fact table. But if you want to use separate ones for each fact table, maybe because you think in the future they might be used differently, then you can.
In short, either way works fine, so whatever makes the most intuitive sense to you and other users is the way you should go.
Yes, that is the purpose of Role Playing Dimensions. When two or more columns in the same fact table reference the same dimension.
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 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.