@wilderman.maudie,
The reason the x-axis of your visual adjusts based on the slicer is that they are both representing the same data from the DateRangePeriod table.
The calculated table you created DateRangePeriod defines a range of dates based on some predefined periods like “Yesterday”, “Last Week”, “Last Month”, etc. When you use a slicer with this table, you’re essentially selecting a subset of dates.
Your y-axis is [Close price] and it’s defined as
Close price = CALCULATE(MAX(AAPL[Adj Close]), Dates[Date]=MAX(Dates[Date]))
It’s calculating the maximum adjusted close price for the most recent date in the Dates table. This measure doesn’t take the date range from the slicer into account, hence it will always return the adjusted close price for the latest date irrespective of the slicer selection.
Try this measure instead:
Close price =
CALCULATE(
SUM(AAPL[Adj Close])
, Dates[Date] IN VALUES(DateRangePeriod[Date])
)
Instead of always using the latest date, this revision now considers all the dates from the selected range in the slicer.
This assumes that each date has only one adjusted close price. If there’s any possibility of multiple entries for the same date, this measure will return incorrect results. If, on the other hand, you want to see the maximum closing price over the selected range (i.e., highest closing price in the selected period), then the measure should use the MAX aggregation.
When you select a date range using the slicer, the DateRangePeriod table gets filtered. Since there’s a bidirectional relationship between Dates and AAPL , the filter context also propagates back to the AAPL table. This means that not only does the Dates table get filtered based on the slicer selection, but the AAPL table also gets filtered to show only rows corresponding to the selected dates.
Perhaps you want that bidirectional filter because you want other visuals (that don’t explicitly use the DateRangePeriod table) to also respond to the slicer selection. For example, if you have another visual that simply plots data from the AAPL table without any measures, the bidirectional filter will ensure that this visual also gets updated based on the slicer selection. Or, you may have other measures that aggregate data from the AAPL table and you want them to respect the slicer’s date range without explicitly referencing the DateRangePeriod table in those measures.
You don’t need that bidirectional filter if you are only interested in filtering the AAPL table based on the slicer when you are explicitly referencing the DateRangePeriod table in your measures. In this case, making the relationship one-directional (from Dates to AAPL ) and explicitly using the DateRangePeriod table in your measures will suffice.
I say that because bidirectional filters can cause problems like circular referencing and make your data model hard to understand. They can also degrade performance.
I hope this helps.