As we know When a cube is built, tuples are created by dimensions and some aggregations applied. Know I faced with a special type of dimension that it's members aren't collectable. For example please consider actor type dimension:
Code Desc
----------------------------------
1 Vendor
2 Employee
3 Unemployed
The point is that I never want to aggregation for Vendor or Employee or Vendor or Employee or Unemployed. My problem is just about comparing these items with together. I only want to compare Vendor with Employee or Employee with Unemployed. So I think in cube there are some aggregations that I don't need to them.
Is there any way to handle this dimension? Is there any dimension type?
Thanks
For the beginning you don't need ALL member in attribute hierarchy, so you could set IsAggregatable property to false.
But, this will not prevent aggregation if you select for example two members (Employee and Vendor) in the filter. For this purpose you will need some kind of scope assignment against your dimension.
Related
I use PSW 3.5.11. I have a classic dimension for people (sex, ethnicity, religion, study level, etc.) and people code.
How can I create this dimension to use each attribute alone and not as a level?
I know how create a dimension with hierarchy, like
geography: Country -> Province - > Region -> City
but Geography dimension not has same structure of People dimension.
How analyze my data by sex in a report, by ethnicity in another report? How can I create the People dimension?
Thanks for the help.
You can reference the same table multiple times.
Define one dimension gender, pointing to the table and a single level gender given by column gender; set another dimension ethnicity, pointing to the same table and a single level ethnicity given by column ethnicity. Etc.
If you prefer, you can instead set multiple hierarchies, one for each attribute, all within a single dimension People, but in practice there isn’t much difference (the MDX changes just a bit).
I have 2 fact tables with a measure group each, Production and Production Orders. Production has production information at a lower granularity (at the component level) productionorders has information at a higher level (order level with header quantities etc.).
I have created a surrogate key link between the two tables on productionorderid. As soon as I add Prod ID (from productiondetailsdim) to the pivot table it blats out the actual qty (from prod order measure group) and I cannot combine the qty's from the two measure groups.
How can I design the correct relationship between the two? Please see my dim usage diagram. Production Details is the dim that links the two fact tables, at the moment DimProductionDetails is in a fact relationship with Production. I'm not sure what the relationship should be with Production Order (it is currently many to many).
Please see example data between the two tables:
I have to be able to duplicate this behaviour:
Do you want the full actual qty from prod order measure group to repeat next to each product? If so a many-to-many relationship is right. I suspect once I explain how that many-to-many works you will spot the problem.
When you slice full actual qty from prod order measure group by product from the Production Details dimension it does a runtime join between the two measure groups on the common dimensions. So for example, if for if order 245295 has a date of 1/1/2015 while the production details for order 245295 have dates of 1/8/2015 then the runtime join will lose rows for that order and actual qty will show as null. So compare all the dimensions used on both measure groups and ensure all rows for the same order have the same dimension keys for those common dimensions. If for example dates differ then create a named query in the DSV that selects just the dimension columns from the production fact table which match the order fact table. Then create a new measure group off that named query and use the new measure group as the intermediate measure group in your many to many dimension. (The current many to many cell in the dimension usage tab should say the name of the new measure group not the existing Production measure group.)
Edit: if you want the actual qty measure to only show when you are at the order level and be null at the product level then try the following. Change the many-to-many relationship to a regular relationship and in the dialog where you choose how the fact table joins to the dimension change the dimension attribute to ProductionOrder_SK (which is not the key of the dimension) and choose the corresponding column in the fact table. Then left click on the Production Order measure group and go to the Properties window and set IgnoreUnrelatedRelationships to false. That way slicing actual qty by work center or by an attribute that is below grain in the Production Details dimension will show as null.
Can Dimension Table became a fact table as well? For instance, I have a Customer dimension table with standard attributes such as name, gender, etc.
I need to know how many customers were created today, last month, last year etc. using SSAS.
I could create faceless fact table with customer key and date key or I could use the same customer dimension table because it has both keys already.
Is it normal to use Customer Dimension table as both Fact & Dimension?
Thanks
Yes, you can use a dimension table as fact table as well. In your case, you would just have a single measure which would be the count - assuming there is one record per customer in this customer table. In case you would have more than one record per customer, e. g. as you use a complex slowly changing dimension logic, you would use a distinct count.
Given your example, it is sufficient to run the query directly against the Customer dimension. There is no need to create another table to do that, such as a fact table. In fact it would be a bad idea to do that because you would have to maintain it every day. It is simpler just to run the query on the fly as long as you have time attributes in the customer table itself. In a sense you are using a dimension as a fact but, after all, data is data and can be queried as need be.
I have a cube with a measure called FactSales, which has entries for each day.
I have three Dimensions, Date, Customer and CustomerType.
Each FactSales row is linked to a date and customer by foreign key. customer is linked to customer type by foreign key.
From this I am able to spit out all sales figure for each customer on each date which is great.
I have multiple types : typeA, typeB, typeC, typeD, typeE.
What I want though is to create two calculated members which have the values aggregated for each customer by typeA, and then by everyother type.
What I have at the moment is something like
Case
When IsEmpty( [Measures].[FactSales] ) or [Customer].[CustomerType].currentmember <> [Customer].[CustomerType].&[typeA]
Then null
ELSE ([Customer].[CustomerType].&[typeA], [Measures].[FactSales] )
END
but I think this is wrong, and i also can't use this same method to get the value of all the other types excluding the typeA. I also dont get the aggregation when i roll it up to a higher level.
Can anyone help? I may not have explained my self well enough so please let me know if you need more info.
Why you are trying to do that? It's not good to store any calculation that is not related to single fact, data in fact table row should correspond only to one system fact (order, job, etc), and with aggregation you will be able to get data based on any dimension.
Your current structure is well and you can easily get calculations by slicing the cube over customer type dimension.
I am trying to build a calculated measure in SSAS that incorporates a dimension parameter. I have two facts: Members & Orders and one Dimension: Date. Members represents all the unique members on my site. Orders are related to members by a fact key representing a unique user. Orders also contains a key representing the vendor for an order. Orders contains a key to the date dimension.
FactMember
- MemberFactKey
- MemberId
FactOrder
- FactOrderKey
- OrderId
- FactMemberKey
- DimVendorKey
- DimDateKey
DimDate
- DimDateKey
- FYYear
The calculated measure I am trying to build is the number of unique vendors a member has ordered from. The value of the calculation must of course change based on the date dimension.
Wouldn't the DISTINCTCOUNT function be the one to use here? Creating a distinct count of Vendors could then be used in this query and elsewhere.
WITH MEMBER [Test]
AS
DISTINCTCOUNT([Vendor].[Vendor].[Vendor])
I will say in advance that this may well be slow (Depending on data volume/distribution), so if this query will be a popular/big part of the design it may be worth considering a restructure.
I am confused, it would make more sense to make Members and Orders both separate dimensions and then reference them from a FACT table, say Fact.Sales. This would eliminate the need to even build a calculated member if you keyed your Members dimension on some sort of member_key.