Щотижневі розрахунки DAX – проблеми з розвідкою часу LuckyTemplates

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

Нещодавно я провів навчальний посібник із отримання значень попереднього тижня в LuckyTemplates. Відтоді у мене виникло кілька запитань, пов’язаних із розвідкою часу, зокрема щодо тижневих значень DAX. Це не дивно, оскільки тижні насправді є найпоганішою гранулярністю в сфері інтелекту часу.

Що стосується місяців, у вас завжди є 12 місяців у році. У випадку з чвертями у вас завжди є чотири чверті. Тижні відрізняються, тому що в тижні сім днів і 52 тижні в році – це 364 дні. Отже, у вас є додатковий день. У високосні роки у вас є два додаткові дні.

Таким чином, через деякі роки, на основі схеми нумерації для номера тижня ISO, іноді буде 52 тижні, іноді 53 тижні. 53 тиждень – це той, який спричинить найбільше проблем.

Зміст

• Питання аналізу часу щотижневого розрахунку DAX
• Висновок

Питання аналізу часу щотижневого розрахунку DAX

У цьому прикладі я використовую загальну спотову ціну. З підсумками легше візуалізувати та говорити про них.

У цьому випадку для кожного року ми хочемо показати рядок для 53-го тижня, незалежно від того, був 53-й тиждень у цьому році чи ні. Отже, ви можете побачити, що в 2018 і 2019 роках немає 53 тижня, але в 2020 році він є. Ми хочемо, щоб це було узгоджено, щоб 53-й рядок був у кожному році. Але тоді показник буде порожнім для років, у яких не було 53-го року.

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

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

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

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

У цьому випадку CROSSJOIN бере два стовпці та створює кожну комбінацію цих двох стовпців, незалежно від того, існує вона в наборі даних чи ні. Це саме те, чого ми хочемо.

Ми маємо створити таблицю зі стовпця. CROSSJOIN бере дві таблиці, а потім VALUES за номером тижня ISO, і ми просто зіставляємо їх разом. Це дасть нам 53 тижні на рік.

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

Однак нам потрібно ще трохи попрацювати, оскільки ключове поле в таблиці Dates працює так: це чотиризначний дефіс року, а потім двозначний тиждень. Отже, у випадках, коли номер тижня ISO складається з двох цифр, ми можемо просто виконати просте об’єднання. У випадках, коли це одна цифра, нам потрібно взяти номер року, а потім об’єднати його дефісом, потім нулем на початку, а потім номером тижня.

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

Якщо ми повернемося до візуалізації, ми повинні змінити рядки. Замість номера року та тижня ми хочемо використовувати номер року та тижня з таблиці CROSSJOIN. І тепер у нас є 53-й тиждень у 2018 році з пробілом і 53-й тиждень у 2019 році з пробілом. У 2020 році ми маємо фактичну кількість, оскільки він має 53-й тиждень.

Ми могли б зупинитися на цьому, за винятком того факту, що зараз ми перейшли з моделі Star Schema. Щоразу, коли ви відходите від зіркової схеми в LuckyTemplates, ви виходите за межі того, що зазвичай вважається найкращою практикою.

Отже, для Snowflake Schema це не є серйозним порушенням. Бувають випадки, коли ви можете точно захотіти ним скористатися, але якщо можете цього уникнути, спробуйте. Це справді зменшує дублювання, але не обов’язково розмір. Це дозволяє використовувати прямі показники підрахунку, але є проблеми з продуктивністю та потенційні проблеми з зручністю використання, і, безумовно, збільшується складність DAX. Це заважає вам будувати ієрархії між таблицями, і, мабуть, найбільшою проблемою є те, що це може справді зіпсувати вашу здатність синхронізувати зрізи в різних полях.

Таким чином, хоча це вирішує проблему, це робить це не дуже добре. Давайте подивимося, чи зможемо ми зробити краще, ніж це. Давайте перейдемо до іншої моделі даних. У цій моделі я взяв ті самі дані, дати та спотову ціну, але цього разу я видалив таблицю CROSSJOIN. Він все ще існує, але не пов’язаний.

Але якщо ми подивимося на DAX, то побачимо, що це той самий DAX, який створив цю таблицю в іншому звіті. Отже, замість того, щоб з’єднувати це у фізичний зв’язок, а потім порушувати схему «зірка» та перетворювати її на схему «сніжинка», ми можемо підтримувати схему «зірка» та просто використовувати віртуальний зв’язок.

Для цього ми використаємо функцію під назвою. Він створює цей зв’язок між таблицями, але робить це віртуально. Ми робимо це за допомогою, оскільки ми збираємося змінити контекст. У цьому випадку контекст стосуватиметься відносин. Отже, у нас є загальна спотова ціна, а потім у нас є TREATAS. Ми маємо можливість перетворити цей стовпець на таблицю.

А потім у нас є поле «Рік і тиждень», яке є ключем, який ми створили. У нас це віртуально об’єднано з тижнем і роком у таблиці дат. Отже, тепер у нас є таблиця Crossjoint, яка фільтрує таблицю Dates так само, як і під час фізичного зв’язку, але без порушення зіркової схеми.

Тепер ми можемо взяти та опустити загальну спотову ціну TREATAS у матрицю, і ми побачимо ті самі підсумки. Таким чином, ми зробили це, не порушуючи нашу модель даних і не зазнаючи жодних недоліків, про які ми говорили у зв’язку зі схемою Snowflake.

Висновок

У цьому підручнику я показав вам кілька способів вирішення проблеми щотижневого обчислення DAX у LuckyTemplates. Перший – за допомогою CROSSJOIN, але він має деякі недоліки. Другий спосіб — це використання TREATAS, створення віртуального зв’язку та не порушування підходу Star Schema.

Це одна з технік, яка дуже корисна для вирішення проблеми 53 тижня. Сподіваюся, ви знайшли це корисним. Я хочу знати вашу думку з цього приводу. Дайте мені знати в коментарях нижче.

Все найкраще,