У меня есть мера, которая подсчитывает строки таблицы, игнорируя фильтрацию по переменной зачисления в высшие учебные заведения:
count_ignore_ps = CALCULATE(COUNTROWS(highschool_recent_year), REMOVEFILTERS(highschool_recent_year[ps_enr]))
Вот он используется в кластерной гистограмме в качестве оси Y. По оси X обозначено обучение в школах и высших учебных заведениях. При таком использовании мерой должно быть общее количество рядов в школе. Это работает так, как задумано на левом графике, но не на правом графике.
На левом графике есть фильтры:
На правом графике есть фильтры:
Есть только три школы, поэтому никаких фильтров по школам и объединение всех школ должно быть одинаковым. Эта мера дает другой результат.
Я думаю, это связано с тем, что 10 учащихся расы 1 зачислены и 0 учащихся расы 1 не зачислены в школу А. Поэтому по какой-то причине эта мера не учитывает учащихся в другом условии.
Кто-нибудь знает, что может быть причиной этой проблемы или решения?
Вот ссылка на данные игрушки: https://drive.google.com/file/d/143r4Nlmz819kdvaBCz6KFdkxAVP0R5ov/view?usp=sharing
Вот ссылка на файл powerbi: https://drive.google.com/file/d/1fYP1Akv2wY2vIy9mRMrl3O26WpHwTtPk/view?usp=sharing
Я вполне уверен, что это существует автоматически. Вы применяете два фильтра к одной и той же таблице, что приводит к срабатыванию автоматического существования. Подробнее здесь: https://www.sqlbi.com/articles/understanding-dax-auto-exist/
Если вы используете звездообразную схему, она работает как положено.
Ваш первый запрос выглядит так:
DEFINE
VAR __DS0FilterTable =
TREATAS({"Race 1",
"Race 3",
"Race 2"}, 'sim_data_norace1_not_enrolled'[race])
VAR __DS0Core =
SUMMARIZECOLUMNS(
'sim_data_norace1_not_enrolled'[school],
'sim_data_norace1_not_enrolled'[ps_enr],
__DS0FilterTable,
"count_ignore_ps", 'sim_data_norace1_not_enrolled'[count_ignore_ps]
)
VAR __DS0PrimaryWindowed =
TOPN(
1001,
__DS0Core,
'sim_data_norace1_not_enrolled'[school],
1,
'sim_data_norace1_not_enrolled'[ps_enr],
1
)
EVALUATE
__DS0PrimaryWindowed
ORDER BY
'sim_data_norace1_not_enrolled'[school], 'sim_data_norace1_not_enrolled'[ps_enr]
И твой второй:
DEFINE
VAR __DS0FilterTable =
TREATAS({"School A",
"School B",
"School C"}, 'sim_data_norace1_not_enrolled'[school])
VAR __DS0FilterTable2 =
TREATAS({"Race 1",
"Race 3",
"Race 2"}, 'sim_data_norace1_not_enrolled'[race])
VAR __DS0Core =
SUMMARIZECOLUMNS(
'sim_data_norace1_not_enrolled'[school],
'sim_data_norace1_not_enrolled'[ps_enr],
__DS0FilterTable,
__DS0FilterTable2,
"count_ignore_ps", 'sim_data_norace1_not_enrolled'[count_ignore_ps]
)
VAR __DS0PrimaryWindowed =
TOPN(
1001,
__DS0Core,
'sim_data_norace1_not_enrolled'[school],
1,
'sim_data_norace1_not_enrolled'[ps_enr],
1
)
EVALUATE
__DS0PrimaryWindowed
ORDER BY
'sim_data_norace1_not_enrolled'[school], 'sim_data_norace1_not_enrolled'[ps_enr]
Обратите внимание, что два фильтра объединены во втором запросе, и, как вы указали, у вас нет «Гонка 1 не зарегистрирована».
Как заметил Дэвид, это похоже на функцию «автосуществования» Power BI. https://www.sqlbi.com/articles/understanding-dax-auto-exist/
ИМХО, это досадная ошибка в движке Power BI, и единственное жизнеспособное решение — создать «таблицы измерений» для атрибутов, которые необходимо фильтровать.
В этом примере я создал «таблицу измерений» под названием «Расы», связал ее с вашей таблицей и заменил существующий фильтр уровня страницы на «Расы[раса].
https://1drv.ms/u/s!AmLFDsG7h6JPiI0t_-0Wx__LjcW4EA?e=RVUrEW
Этого было достаточно, чтобы решить вашу непосредственную задачу, но в вашей реальной модели я бы рекомендовал вам проработать и создать аналогичные таблицы для других атрибутов, которые вы используете для фильтров или в качестве измерений в своих визуальных элементах.
Я предпочитаю создавать такие таблицы с помощью Power Query — полагаться на DAX более хрупко, и легко создать проблемы с циклическими зависимостями (еще одна ошибка, IMO, на другой день...).
В моих реальных данных есть несколько категорий, которые я буду считать. Должен ли я составить таблицу «Расы», «Школы», «Доход» для каждой категории с объединением от 1 до многих с основной таблицей?
@VictorFeagins да, именно. Вам придется быть осторожным и заменять ссылки на эти текущие поля (в фильтрах, полевых колодцах и т. д.) эквивалентными полями из новых таблиц измерений.
Джеффри Ван заявил в сообщении на Reddit 3 года назад, что они планируют «исправить» это поведение. К сожалению, обновлений пока нет, и это обычная ловушка, в которую попадают люди, особенно те, кто думает, что PBI — это взять и поиграть.