Юрий, извините, не могли бы показать на примере кода. Я вас не очень понял

Спасибо все верно! на Слайдер был наложен фильтр.

С тел неудобно писать

Привет!
Отчет на DQ, данные в источнике обновляются раз в 5 минут
Добавил из него визуал в панель мониторинга
Настроил оповещения
Правильно ли я понимаю что он будет проверять данные раз в час и если что присылать оповещени?

Всем привет!
Похоже сегодня день вопросов про DQ, задам и я свой)
Есть огромная таблица (события мобильной аналитики) и есть множество полей, по которым надо фильтровать/группировать данные.
Есть 2 варианта модели данных:
1. Звезда, в которой таблицы измерений обычно состоят из 2х-3х столбцов - ключ, индекс для сортировки и более приятное глазу название измерения.
Минус: использование полей из справочников увеличивает сложность запросов (джойны и все такое).
2. Одна таблица фактов, фильтрация/группировка происходит по полям из неё же, индексы также внутри таблицы фактов (генерятся на стороне источника и физически хранятся в витрине).
Плюсы: работает гораздо быстрее.
Минусы: морально тяжело отказаться от звезды 😄
Кто что скажет, ок ли второй вариант, какие тут вообще бест практики? Доки читал, оптимизации для dq делал, но рекомендаций по модели данных для DQ не видел)
Источник - колоночная БД, если что)

Лучше сделать максимально просто предварительно по максимуму все рассчитав на sql,

Проблема с которой я столкнулся в схеме звезды: визуалы не успевали рассчитываться и отваливались по таймауту в итоге отчёт становился полупустым

P s бд ms sql

Как-то тут уже писали, что вообще, надо звезду, но если прям таблица одна, и там все есть, то вполне рабочий вариант табличка + календарь (отдельно). И я за него))) Конечно, еще вопрос, а насколько большая табличка и пр.

Опять же справочники обогощаются проще. Но если вам не особо надо и в табле вашей все есть, см. пост выше

Да, в таблице все есть, т.к. база колоночная, не любит джойны, любит кучу столбцов) Поэтому таблицы измерений - по факту искусственно созданные, вручную либо как дистинкт по полю из таблицы фактов)
В том и дело, что справочники не особо то обогащены информацией 😁 Так что больше нужна моральная поддержка в отказе от звезды)) Спасибо!

Главное помнить, что измерения из таблицы фактов не создают контекст вычисления для строк, которые в ней отсутствуют. А если измерения из справочников, то создают. Года два назад тыкался с одной проблемой в сложном расчёте, пока Максим Зеленский носом не ткнул. Так что имейте в виду.

+ + - это то, с чем сталкиваться приходится нечасто и каждый раз втыкать заново.

Не уверен, что до конца понял о чем вы)
Вы про то, что если у меня например ассортимент из 3-х товаров, но продажи были только по 2-м, то о том, что товар 3 не продается я не узнаю, если буду брать измерения из фактов?)
Если так, то это не мой случай - как я писал, все измерения я итак вытаскиваю из широкой таблицы фактов)

Я про то что если не было продаж по товару1 в декабре, но надо чтобы в этой ячейке на визуале что-то посчиталось. То там ничего не посчитается, т.к. нет контекста.

Если за последние 3 года в этом ничего не поменялось то примерно такая проблема.

Если же измерения из справочника то движок соорудит кроссджойн справочника с календарем, а в ячейку отчёта положит тот результат что вам нужен.

Коллеги, спасибо за выпуск!)
Ждём новых интервью)

Всем привет! У меня вопрос связан с загрузкой данных из MySQL базы в PBI. Возможно, кто-то сталкивался.
Дело в том, что это мой первый проект, поэтому я пока что не совсем понимаю, что в целом представляет из себя MySQL база))

Собственно сам вопрос:
У нас в базе есть таблица с данными, и если подключиться к самой базе, то попадаешь сперва на верхний уровень - там перечислены названия столбцов, тип данных в них и собственно *комментарии*.

Потом уже можно провалиться в саму таблицу с данными, где столбцы названы кодировкой.

Дело в том, что при подключении этой базы к PBI, он видит лишь нижний уровень этой таблицы. Поэтому у меня в итоге нет никакой возможности присоединиться непосредственно к "верхнему" уровню, где и лежат *комментарии* - это расшифрованные названия закодированных столбцов.

Подскажите, можно ли как-то пофиксить эту проблему, или же PBI не умеет добираться до таких данных?