I have a measure table for forecast that has a MMM-YY date stored as text;
Period Forecast
-------------------
Jan-20 200
Feb-20 300
I also have some other tables in my model that have similar date formats ie. (1/2020) or 2020_1. Hence I created a date dimension that maps the period to an actual datetime and linked it to the fact table;
Period (Month/Year) Year_Month MonthEnd
---------------------------------------------------
Jan-20 (1/2020) 2020_1 31/01/2020
Feb-20 (2/2020) 2020_2 28/02/2020
This is causing me two issues;
If I slice the forecast by period I get the right answer, but if I slice by the datetime field 'MonthEnd', SSAS can't allocate the costs across the attributes and I get the total each month (so 500 in both jan and feb in this example). Why?
I can't connect time as a referenced dimension to the date dimension so I can't use any time intelligence features.
I could just swap the period ID for a datetime on ETL to standardise the date fields across the model, but I wondered if there was a standard way to approach this?
https://imgur.com/gallery/onxtvhq
In Analysis Services Multidimensional models you need to standardize on one format for representing a period and have all measure groups use that. I would recommend you change the SQL Query for your Actuals measure group to return values that join to the Period column in your Date table.
Understanding how this works means understanding attribute relationships and the IgnoreUnrelatedDimensions setting. If set to true then slicing by an “unrelated” attribute (one that’s below the grain or unrelated or an unrelated dimension) will just cause the measure to repeat. If set to false then it will become null.
I’m unclear why you need Time as a reference dimension. It appears to also contain a Date hierarchy. Typically Date is for days, weeks, months and years. Typically Time is for hours minutes and seconds. For processing performance reasons I would avoid reference dimensions. They are more trouble than they are worth. Add the Time dimension key to your fact tables.
The scrrenshot shows there is relation between Date and Forcast,so I do not think the root cause that is the root casue,however, you can try GreGalloway's solution, to set the property of IgnoreUnrelatedDimensions to False to test.
enter image description here
Related
Background: I have a column in a Customer dimension with a static date(e.g '2013-01-01').
This column is the result of a calculation that gets the first transaction date ever made by that certain customer. This customer dimension is linked to a fact table containing reportdate as a date column linked to a date dimension.
Goal: I want to make a calculated measure that, based on a sum of amount measure, calculates the result based on a given period between start_date(First transaction date), end_date (first transaction date + 6 months).
All i get is "cannot be determined in the current context" warnings and cannot get my head around to fix it.
All help is welcome!
Thanks in advance,
/Blixter
SOLVED I replicated the logic from the calculated measure found in the Customer table.
=CALCULATE([SumAmount];DATESBETWEEN(DimDate[Date];FIRSTDATE(FactTable[Reportdate]);DATEADD(FIRSTDATE(FactTable[Reportdate]);5;MONTH)))
I have two questions.
Source table contains data at weekly level.
We have a fact table with Week_Key, Month_Key, Quarter_Key (& a beautiful time dimension).
Would it be possible to load-populate Month_Key & Quarter_Key in the
fact table for the source data which is at weekly granularity ?
Problem here would be the last week of the month which falls under
the current month & the next month.
Anyhow if we load weekly data by populating the Month_Key
(considering current month for last week) & so Quarter_Key, would it
be possible to aggreate data Monthly & Weekly seperately at report
level ?
Your thoughts on this would be very helpful ...
If I understand correctly, you have multiple different rollups and you are trying to handle them.
I think the best solution is for the fact table to be at a daily granularity. This is the unit of time that best rolls up into weeks, months, and quarters.
The time dimension would then contain the week, month, and quarter values for all days.
You would then roll-up the data to the appropriate level for reporting purposes. If the data is very voluminous, you may also incorporate summary tables at common levels of aggregation to improve performance for users.
Data: I have a single row that represents an annual subscription to a product, it has an overall startDate and endDate, there is also third date which is startdate + 1 month called endDateNew. I also have a non-related date table (called table X).
Output I'm looking for: I need a new column called Categorisation that will return 'New' if the date selected in table X is between startDate and endDateNew and 'Existing' if the date is between startDate and endDate.
Problem: The column seems to evaluate immediately without taking in to account the date context from the non-related date table - I kinda expected this to happen in visual studio (where it assumes the context is all records?) but when previewing in Excel it carries through this same value through.
The bit that is working:I have an aggregate (an active subscriber count) that correctly counts the subscription as active over the months selected in Table X.
The SQL equivalent on an individual date:
case
when '2015-10-01' between startDate and endDateNew then 'New'
when '2015-10-01' < endDate then 'Existing'
end as Category
where the value would be calculated for each date in table X
Thanks!
Ross
Calculated columns are only evaluated at model refresh/process time. This is by design. There is no way to make a calculated column change based on run-time changes in filter context from a pivot table.
Ross,
Calculated columns work differently than Excel. Optimally the value is known when the record is first added to the model.
Your example is kinda similar to a slowly changing dimension .
There are several possible solutions. Here are two and a half:
Full process on the last 32 days of data every time you process the subscriptions table (which may be unacceptably inefficient).
OR
Create a new table 'Subscription scd' with the primary key from the subscriptions table and your single calculated column of 'Subscription Age in Days'. Like an outrigger. This table could be reprocessed more efficiently than reprocessing the subscriptions table, so process the subscriptions table as incrementals only and do a full process on this table for the data within the last 32 days instead.
OR
Decide which measures are interesting within the 'new/existing' context and write explicit measures for them using a dynamic filter on the date column in the measures
eg. Define
'Sum of Sales - New Subscriptions',
'Sum of Sales - Existing Subscriptions',
'Distinct Count of New Subscriptions - Last 28 Days', etc
I want to model a fact table for our users to help us calculate DAU (Daily active Users), WAU (Weekly active users) and MAU (Monthly active users).
The definitions of these measures are as follows:
1. DAU are users who is active every day during last 28 days.
2. WAU are users who are active at least on one day in each 7 days period during last 28 days
3. MAU are users who are active at least 20 days during last 28 days
I have built a SSAS cube with my fact table and user dimension table as follows
Fact : { date, user_id, activity_name}
Dimension: { date, user_id, gender, age, country }
Now I want to build a cube over this data so that we can see all the measures in any given day for last 28 days.
I thought of initially storing 28 days of data for all users in the SQL server and then do count distinct on date to see which measures they fall into.. but this proved very expensive since the data per day is huge..almost 10 millions rows.
So my next thought was to model the fact table (before moving it to SQL) such that it has a new column called "active_status" which is a 32 bit binary type column.
Basically, I'll store a binary number (or decimal equivalent) like 11000001101111011111111111111 which has a bit set on the days the user is active and off on the days user is not active.
This way I can compress 28 days worth of data in a single day before loading into data mart
Now the problem is , I think MDX doesn't support bitwise operations on columns in the expressions for calculated members like regular SQL does. I was hoping to create calculated measures daily_active_users, weekly_active_users and monthly_active_users using MDX that looks at this active_status bit for the user and does bitwise operation to determine the status.
Any suggestions on how to solve this problem? if MDX doesn't allow bitwise, what else can I do SSAS to achieve this.
thanks for the help
Additonal notes:
#Frank
Interesting thought about using a view to do the conversion from bitset to a dimension category..but I'm afraid it won't work. Because I have few dimensions connected to this fact table that have many-many relationships..for ex: I have a dimension called DimLanguage and another dimension called DimCountry and they have many-many relationship. And what ultimately I would like to do in the cube is to calculate the DAU/WAU/MAU which are COUNT(DISTINCT UserId) based on the combination of dimensions. So for ex; If a user is not MAU for dimension country US because he is only active 15 days out of 28 ....but he will be considered
You do not want to show the bitmap data to the users of the cube, but just the categories DAU, WAU, MAU, you should do the conversion from bitmap to category on data loading time. Just create a dimension table containing e. g. the following data:
id category
-- --------
1 DAU
2 WAU
3 MAU
Then define a view on your fact table that evaluates the bitmap data, and for each user and each date just calculates the id value of the category the user is in. This is then conceptually a foreign key to the dimension table. Use this view instead of the fact table in your cube.
All the bitmap evaluations are thus done on the relational side, where you have the bit operators available.
EDIT
As your requirement is that you need to aggregate the bitmap data in Analysis Services using bitwise OR as the aggregation method, I see no simple way to do that.
What you could do, however, would be to have 28 single columns, say Day1 to Day28, which would be either 0 or 1. These could be of type byte to save some space. You would use Maximum as aggregation method, which is equivalent to binary OR on a single bit.
Then, it would not be really complex to calculate the final measure, as we know the values are either zero or one, and thus we can just sum across the days:
CASE
WHEN Measures.[Day1] + ... + Measures.[Day28] = 28 THEN 'DAU'
WHEN Measures.[Day1] + ... + Measures.[Day7] >= 1 AND
Measures.[Day8] + ... + Measures.[Day14] >= 1 AND
Measures.[Day15] + ... + Measures.[Day21] >= 1 AND
Measures.[Day22] + ... + Measures.[Day28] >= 1 THEN 'WAU'
WHEN Measures.[Day1] + ... + Measures.[Day28] >= 20 THEN 'MAU'
ELSE 'Other'
END
The order of the clauses in the CASE is relevant, as the first condition matching is taken, and your definitions of WAU and MAU have some intersection.
If you have finally tested everything, you would make the measures Day1 to Day28 invisible in order not to confuse the users of the cube.
I have just started tinkering with MS SQL Analysis Services. For a start, I'm creating one cube from sales detail table. For the dimensions I have created ProductDim from product master table, LocationDim from location tables, and a CalendarDim.
However I'm stuck when trying to provide these data:
boolean: how do I let user filter active/inactive transactions? Should I create a dimension containing 2 values, TRUE and FALSE?
time: should I create a dimension containing 00:00:00 to 23:59:59 or should I merge time into my calendar dimension?
transaction count: one transaction can have many line items, there's line item id, and there's transaction id, how do I set the dimension so user can see transaction count? Because the count of the measure is line item count.
So, I've been reading about this quite a bit recently, and I will try to answer each one as much as theory suggests:
For this, you should create something called 'junk' dimension: its basically a dimension with no attributes. http://en.wikipedia.org/wiki/Dimension_(data_warehouse)
You probably don't want the time dimension merged with calendar. You'll end up storing way too many records. If your granularity is minute, then one day would be 24 * 60 = 1440 records. You have to decide how granular you want to go (per minute, per second??) And then store an entire days worth of time in a 'Time' dimension. So you fact tables will have two keys, one to your calendar dimension, and one to your 'time' dimension.
Transaction count should be a 'measure', I think (no?). I assume you have transaction id repeated, because you have multiple line items per transaction. When you setup the measure, you can do 'distinct count' of transaction id.