I am new to SSAS and i have a problem with the dimension members for which i haven't been able to find a solution. Is it possible to group dimension members like:
Member 1
Member 2_1
Member 2_2
Member 2_3
Member 3
...
so that the user browsing the cube will see only Member 1, Member 2, Member 3.
You could group the dimension members on the way into the cube (within your etl or views), but you will have to group the related fact records for it to make sense. If the dimension should be treated as the collected set and not subdivided this would be preferable.
Alternatively, if the sub dimension values make sense on their own and should be persisted alongside, you could create a hierarchy of members within SSAS relating the sub values to your desired parent value.
Related
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.
I have a Plant dimension used with multiple SSAS cube MOLAP measure groups which has 1000's of members in the dimension, each have a related region id property of 1,2,3 or 4.
The dimension is related to the measure groups by both region id & plant code, when I deselect all members for the Region Id property in the role's Dimension Data Tab and select only a few of them I end up with the below MDX in the advanced tab:
{[Plant].[Region Id].&[1]&[1001], [Plant].[Region Id].&[1]&[1002]}
This MDX is showing both the region id and plant code.
The dimension data changes each week and the members will change, I do not want to select 1000s of members to restrict these plants by Region Id for a security role, especially when these will change over time.
How can I apply a rule to restrict this data by the Region Id i.e. RegionId LIKE 1?
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.
I am having a tough time figuring out how I am supposed to implement parent-child relationships between my measure groups in SSAS. Essentially I am just trying recreate a standard SQL join so that I can lookup measures in my Parent group while using keys in my Child group.
For example, let's say I have the following dimensions:
Parent
Child (FK: ParentID)
Time
And I have the following measure groups
ParentFact (Keys: ParentID, TimeID - Measures Related to the parent over time)
ChildFact (Keys: ChildID, TimeID - Measures related to the child over time)
I have not created any specific dimensions for any of my fact tables.
In the end I just want to run a query like this to list out measures in my Child table joined to measures in my Parent table:
SELECT
{
[ChildMeasure]
, [ParentMeasure]
} ON COLUMNS
, [Child].Children ON ROWS
FROM
[MyCube]
WHERE
[Time].[100]
When this query runs, the Child rows are correctly listed, alongside the appropriate measure values for Time ID 100. Unfortunately, ParentMeasure is all the same, and appears to be an aggregate for this value over all Parents at Time ID 100. I would expect this column to show the value from each child's associated parent at Time ID 100.
What am I doing wrong here? Do I need to create FactDimensions for each FactTable, and somehow relate those? Should I crate an association between Parent and Child in my Datasource view? Would that make it a Snowflake schema, which I think I am supposed to avoid?
As a side note, my ChildFact table actually contains ParentID as one of the measures, because it is on the relational table in the datasource (probably due to some previous denormalization effort by the DB developer). Should I remove any measures that are actually FKs in my fact table, or is that somehow required for what I am trying to do?
I don't think you should attempt to create a single Fact table due to the obvious granularity issue.
I think you should add a Dimension Relationship in your Cube definition, between your Child Fact and Parent Dimension, using the existing FK column.
Probably the only valid use of ParentID as a Measure would be to get a Distinct Count.
There is no need to create two facts here.
Create a single Fact table (ParentID, ChildID, TimeID)
Create 3 dimension DimParent, DimChild, DimTime
FK of Fact table will refer to respective dimension table
Also, check the Attribute relationship how Facts are sliced with 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.