The solution you found is based on a scenario where you have two distinct date dimensions, one for start date and one for end date. But the complexity of your case resides in the fact that you need to aggregate your measures based on whether or not a certain date falls within the start and end dates of each case, no matter the dimension chosen (Year, Quarter, Month, Week, Date). In order to implement this, you would need to follow a number of steps:
Step 1: Set up the date dimension
You need to set up a shared date dimension which has Year, Quarter, Month, Week, and Date levels. This dimension is not connected to your fact table directly but used in the calculations.
Step 2: Create a factless fact table
To handle the fact that a single case can span multiple dates, you need a bridge table, often referred to as a "factless fact table". For each case in your Case table, this table will contain a row for each date from the StartDate to the EndDate. The granularity of this table would be on the day level. Here's an example of what this table would look like:
| CaseID | Date |
|--------|------------|
| 1 | 2020-01-01 |
| 1 | 2020-01-02 |
| 1 | 2020-01-03 |
| ... | ... |
| 2 | 2020-02-01 |
| 2 | 2020-02-02 |
| ... | ... |
Step 3: Create a new measure
With the factless fact table, you can create a new measure in your cube for 'CaseCount'. This measure will count the number of distinct CaseIDs in the factless fact table.
Step 4: Utilize the new measure
You can now use this measure with the shared date dimension. Depending on the level you are viewing in your date dimension (Year, Quarter, Month, Week, Date), SQL Server Analysis Services (SSAS) will automatically aggregate the CaseCount accordingly. For example, if you're looking at the Year level, it will sum the CaseCount for all dates within each year.
However, generating and maintaining the factless fact table could be a challenging task, particularly when you have a large amount of data. Alternatively, you might want to consider building a custom MDX expression, or even migrating your cube to a tabular model, where DAX provides more straightforward and efficient methods for solving this type of problem.