Контекст рядка та контекст фільтра в коді LuckyTemplates DAX

У цьому підручнику ми збираємося поглянути на фрагмент коду DAX. Можливо, ви вже використовували щось подібне. Або ви можете натрапити на нього та заплутатися про те, як працює цей код і як, здається, контекст рядка та контекст фільтра взаємодіють один з одним лише в одному коді DAX. У будь-якому випадку, цей підручник детально розгляне все вищезазначене. Ви можете переглянути повне відео цього підручника внизу цього блогу.

Спочатку ми розглянемо сам код. Потім ми розглянемо теоретичну частину, щоб краще її зрозуміти. Нарешті, ми розглянемо все за кадром за допомогою.

Модель даних, яку ми збираємося використовувати, — це, по суті, проста модель даних про продажі, яка містить таблиці «Дати», «Продажі» та «Продукція». Таблиця «Продажі» містить транзакції для кожного заданого дня. Таблиця «Продукти» містить інформацію про продажі продуктів за кожен день. Для цілей цього посібника таблиця Dates містить лише кілька стовпців.

Нас цікавить лише таблиця Dates, але ми збираємося використовувати таблиці Sales і Products, щоб пояснити, як контекст фільтра та контекст рядка поширюються за допомогою зв’язків.

Зміст

• Контекст рядка та контекст фільтра в поточному загальному показнику
• Використання DAX Studio для розуміння контексту рядка та контексту фільтра
• Висновок

Контекст рядка та контекст фільтра в поточному загальному показнику

Тепер давайте створимо поточну загальну міру, оскільки вона містить і рядок, і контекст фільтра. Це базовий поточний підсумковий показник, де я використовую COUNTROWS замість FILTER і функцію ALL, щоб повернути всі роки, які є в таблиці Date. Коли я перенесу цей показник у таблицю нижче, ви побачите, що ми отримуємо очікуваний результат.

Тепер давайте спробуємо проаналізувати, як працює цей код DAX.

У вимірюванні ви можете побачити, що спочатку у нас є COUNTROWS, але це не перша функція, яка оцінюється або виконується. Потім ми маємо функцію FILTER, а потім ALL. Першим у порядку оцінювання є ВСІ. ALL повертає всі унікальні значення Dates Calendar Year Number, ігноруючи будь-який контекст фільтра, який існує поза функцією ALL.

Отже, у показниках у нас є стовпець «Номер календарного року», і він активно фільтрує цей стовпець. Але оскільки ALL ігноруватиме наявний контекст фільтра, ми отримаємо всі унікальні значення цього стовпця.

У другому аргументі в контексті рядка ми написали, що число дат календарного року має бути меншим за число календарного року MAX. Тепер, якщо ви новачок і все ще намагаєтесь зрозуміти та вивчити DAX, ви можете подумати, що посилання ліворуч і всередині функції MAX належать до одного стовпця та є тією самою таблицею, яку ми маємо всередині Функція ALL.

Але це неправда. Єдина частина контексту рядка, яка належить до функції ALL, це та, яку ми маємо ліворуч. Той, який ми маємо на MAX, оцінюється в контексті фільтра, а не в контексті рядка.

Таким чином, FILTER намагається створити контекст рядка в таблиці, який ви надаєте в першому аргументі, і ця частина коду фактично отримується з контексту цього конкретного рядка. Отже, кожен рядок FILTER повторює ту таблицю, яка є всередині ALL, і тоді ми можемо отримати доступ до всіх значень, які ми зараз повторюємо.

Отже, у першій ітерації ми маємо лише одне значення. У другій ітерації ми маємо друге значення. Але коли ми пишемо MAX, це не залежить від контексту рядка, який ми створюємо за допомогою функції FILTER. Таким чином, MAX оцінюється в контексті фільтра, який створюється числом поточного року, яке ми використовували в цій матриці.

Коли ми знаходимося в 2006, MAX поверне 2006, тоді як поточний рядок може бути 2006, 2007 або 2008. FILTER поверне таблицю, яка задовольняє критерії, які ми вказуємо в другому аргументі. Коли ми перейдемо до 2007 року, функція MAX поверне 2007. У 2008 році вона поверне 2008. І залежно від усіх значень, менших за значення, яке повертає функція MAX, FILTER поверне стіл.

Щоб довести, що MAX не залежить від контексту рядка, ми можемо розділити цю частину коду DAX на кілька змінних. І тоді ми зможемо зрозуміти, що посилання на стовпець ліворуч і праворуч не однакові.

Отже, давайте створимо змінну.

Як ви можете бачити в мірі нижче, я створив три змінні (). Потім я додав код FILTER нарешті зі змінною Result, яка використовує. Коли я використаю цей показник у таблиці нижче, ви побачите, що нічого не зміниться. Результати все ті ж. Ми все ще отримуємо ту саму поточну суму, яку отримували раніше.

Якщо ми повернемося до коду та спробуємо отримати значення першої змінної та підтвердимо це, ви побачите, що для кожного рядка ми отримаємо той самий рік.

Тож, сподіваюся, я зміг пояснити вам, що функція MAX у цьому конкретному коді фактично не залежить від реального контексту своїх значень. І якщо ви хочете спростити своє розуміння контексту оцінки, ви завжди можете розбити код на кілька змінних, щоб ви могли зрозуміти порядок оцінки та спосіб виконання коду.

Тепер я хочу показати вам сценарій, у якому функція MAX залежатиме від контексту рядка , створеного функцією FILTER.

Отже, повернемося до цього показника. Давайте скопіюємо це, і замість Last Visible Year я матимуМАКСИМАЛЬНЕ число дат календарного року. Коли я вношу це в матрицю, ви можете побачити, що ми отримуємо порожнє місце.

чому

Справа в тому, що ми повторюємо всі роки, а CALCULATE перетворює поточний рядок у еквівалентний контекст фільтра.

Якщо я напишу тут знак рівності, ви побачите, що ми отримаємо сім, сім і сім.

чому

Дозвольте мені створити нову обчислену таблицю, щоб ви могли легко зрозуміти, що відбувається.

Я створю нову таблицю. Далі я збираюся написатинад УСІМИ датами Номер календарного року. Потім я напишу Макс. рік, а потім використаю ОБЧИСЛЕННЯ над МАКС. числа календарного року. І тепер ви бачите, що для кожного рядка ми повторюємо те саме значення.

Оскільки ці числа не є строго меншими за них самих, ми отримуємо порожнє значення. Але коли ми використовуємо дорівнює (=), ми говоримо, що всі значення, менші за 2011, отримують сімку.

Крім того, навіть якщо ви використовуєте посилання на міру, наприклад щось на зразок Max Year, цей код не працюватиме.

Якщо я натисну кнопку «Підтвердити», ви побачите, що ми нічого не отримуємо. Це пояснюється тим, що коли ми пишемо Максимальний рік, ми просто пишемо РОЗРАХУНУТИ МАКСИМАЛЬНУ дату Номер календарного року.

Посилання на міру завжди має поза ним CALCULATE. Отже, цей захід ініціює перехід контексту, який перетворює поточний ітерований рядок у контекст фільтра.

Але якщо ви зв’язані і вам потрібно використовувати посилання на міру, що ви можете зробити, це зберегти цю міру в змінній. І, як ви, напевно, знаєте, змінні є постійними, і вони не можуть створити контекстний перехід. Тому він не може перетворити контекст рядка в контекст фільтра.

Отже, це коротка демонстрація того, як контекст рядка та контекст фільтра взаємодіють один з одним у коді DAX.

Тепер перейдемо до DAX Studio, щоб зрозуміти, що відбувається за лаштунками.

Використання DAX Studio для розуміння контексту рядка та контексту фільтра

Давайте перейдемо до зовнішніх інструментів і запустимо DAX Studio. Нам потрібно підключитися до файлу LuckyTemplates за допомогою Query Plan і Server Timings .

Потім я збираюся створити міру запиту. Я напишу DEFINE MEASURE у таблиці Dates, Dates Running Total. А потім я використаю вихідний код, який у нас був.

Оскільки ми повинні повернути таблицю, ми можемо написати EVALUATE. Нарешті, ми збираємося створити таблицю за допомогою SUMMARIZECOLUMNS. Отже, ми збираємося написати дати, календарний рік, номер і віртуальний стовпець, який буде поточним підсумком. А потім я можу написати щось на зразок DT як ключове слово DAX Studio.

Якщо я виконаю цей код, ви побачите, що код завершено, і ми все одно отримаємо той самий результат, який бачили в LuckyTemplates.

Тепер давайте перейдемо до плану запиту, щоб зрозуміти, що відбувається за лаштунками. Давайте подивимося, чи насправді функція MAX залежить від контексту рядка чи ні. Давайте перейдемо до логічного плану запиту, оскільки фізичний план запиту, як правило, складніший і його дещо важко читати.

Ви бачите, що перший оператор у першому рядку — GroupSemiJoin , і він використовується SUMMARIZECOLUMNS для створення внутрішнього з’єднання між двома стовпцями.

Потім для об’єднання цих стовпців є Scan_Vertipaq , який є механізмом зберігання, який ми маємо в службах аналізу. Ми бачимо, що там сказано, що нам потрібен стовпець, який є датами, календарним роком, номером. У LuckyTemplates ви можете побачити, що в матриці є цей стовпець «Номер календарного року», який діє як доступ до нашого звіту.

Далі ми маємо функцію COUNTROWS у нашому вимірюванні як оператор верхнього рівня, потім COUNTROWS викликаєдля фільтра. Знову є Scan_Vertipaq , у якому сказано, що RequiredCols — це номер дати календарного року.

Рядки 2 і 5 однакові, але перший Scan_Vertipaq позначено нулем, а другий – одиницею. Це означає, що стовпець, до якого ми звертаємося за допомогою функції ALL, витягується окремо від стовпця, який ми маємо всередині функції SUMMARIZECOLUMNS.

Потім є оператор LessThan . У наступному рядку ми бачимо, що відбувається порівняння між контекстом рядка та функцією MAX .

Далі йде Max_Vertipaq . Отже, ми фактично витягуємо максимальне значення з механізму зберігання. Праворуч ви бачите, що написано DependOnCols Dates Calendar Year Number. Це найважливіше, що ми повинні пам’ятати. Раніше я говорив, що функція MAX не залежить від контексту рядка, і ось що насправді це підтверджує.

Отже, тут написано нуль.

Де ми знайшли нуль?

Зверху (другий рядок), який витягується для SUMMARIZECOLUMNS. Це означає, що функція MAX не залежить від контексту рядка, але насправді залежить від стовпця (номер календарного року), який ми маємо в цій таблиці. Отже, ця таблиця фактично створює контекст фільтра.

Коротше кажучи, функція MAX залежить від контексту фільтра, а не контексту рядка.

Далі ви можете побачити, що для обчислення Max_Vertipaq ми маємо Scan_Vertipaq , який говорить, що DependOnCols нуль (0) дата календар номер року. Крім того, є кілька інших стовпців, для яких потрібні стовпці.

Тепер давайте подивимося на змінну версію коду. Замість повернення LastVisibleYear я збираюся повернути версію COUNTROWS або змінну Result, і ви бачите, що ми все ще отримуємо той самий результат.

Якщо ми подивимося на план запиту, ви побачите, що він трохи довший, але його набагато легше читати.

Нарешті, ось також розрахована версія коду

А ось як виглядає план логічного запиту.

Висновок

У цьому підручнику я пояснив, як дана функція може взаємодіяти та як не може взаємодіяти з контекстом рядка. Я також показав вам, як у цьому випадку MAX було оцінено в контексті фільтра, а не в контексті рядка.

Важливо завжди пам’ятати, що контекст фільтра фільтрує всю модель, а контекст рядка лише повторює дану таблицю і ніколи не фільтрує модель. Контекст фільтра не повторює таблицю.

Сподіваюся, цей посібник був для вас корисним. Слідкуйте за нашимикод, який ми випустимо дуже скоро. Ми розглянемо подібні сценарії набагато глибше. Ми також навчимо вас, як можна оптимізувати свій код DAX.