Практика бизнес-анализа для BI-систем

Как разработчики, мы должны уделять больше внимания модели данных Qlik Sense, чем при разработке в QlikView, поскольку мы ожидаем, что пользователь будет искать больше информации и идей.

Мы также ожидаем, что они будут создавать собственные визуализации на лету, и для этого им нужна понятная модель данных, и с учетом этого нам нужно подумать о том, как мы предоставляем нашим пользователям Измерения, Меры и Визуализации в основных элементах.

В QlikView перед выпуском информационной панели принято помещать все выражения в переменные. На то есть ряд причин:

• Управление метрикой – чтобы знать, что все экземпляры этого показателя будут согласованными, вам нужно всего лишь отредактировать переменную один раз, поскольку все они ссылаются на одну и ту же переменную.
• Иерархическое управление метрикой – для таких мер, как маржа, вместо того, чтобы писать полное выражение, вы ссылаетесь на переменные нижнего уровня для продаж и затрат. Как и прежде, вам нужно только один раз обновить ее, чтобы знать, что все экземпляры этой меры будут согласованы.
• Производительность – малоизвестный параметр. Если у вас есть два выражения “=sum(Sales)” & =”sum( Sales )” (обратите внимание на лишние пробелы во втором выражении!), То механизм анализирует их как два отдельных выражения и, следовательно, для вычисления берет вдвое большую вычислительную мощность. Если бы они были написаны одинаково, то рассчитывались бы один раз, независимо от того, сколько раз они используются.

Зная все эти преимущества, с какой стати мы должны прекратить использовать выражения?

А все из-за пользовательского опыта, если мы используем переменные, когда пользователь хочет отредактировать мастер-меру, у него не будет отличного исходного места для начала работы…

Приведенный выше пример не очень полезен, и пользователь, вероятно, будет разочарован. Я считаю, что читать что-то и понимать контекст намного проще, чем создавать что-то с нуля. Если вы посмотрите на следующий пример, попробуйте взглянуть на него свежим взглядом, как если бы вы были конечным пользователем Qlik:

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

Теперь пользователь может точно видеть, что происходит, даже с добавлением Set Analysis. Большинство пользователей должны иметь возможность редактировать меру или, возможно, сделать еще шаг вперед, используя эту и другие меры в качестве отправной точки для чего-то нового, выбирая информацию из каждого и создавая новый расчет для самостоятельного обнаружения данных.

Как я собираюсь справиться со всей этой дополнительной работой!

Как мы будем управлять этим с точки зрения разработчика? Вот потенциальные проблемы:

1. Быстрое заполнение и, что еще важнее, автоматическое обновление основных элементов с учетом изменений в расчетах.
2. Сокращение дублирования, которое позволит мерам ссылаться на самих себя.

Во-первых, как и большинство разработчиков при работе с переменными, мы по-прежнему можем обрабатывать создание и обновление Мастер-элементов с помощью внешнего файла, такого как рабочая книга. Быстрый поиск «Master» в Qlik Branch Garden приводит к появлению ряда расширений, которые автоматизируют процесс (показано ниже). Это достигается за счет использования мощных API-интерфейсов Qlik.

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

Последнее, что вам нужно учитывать, это Иерархическое Метрическое Управление. Как-то во время разговора мне задали вопрос о Мастер-данных, которые ссылаются друг на друга. В настоящее время это невозможно, хотя я верю, что это вопрос времени. Несмотря на это, я не думаю, что данная мера необходима или вызывает проблему, так как мне пришлось решать аналогичную проблему много лет назад в QlikView!

Задача состояла в том, чтобы автоматически создавать временные итерации для одной и той же метрики, такой как «Вчера», «Прошлый год», «Квартал к дате» и т. д. Я создал сценарий в QlikView, который мог делать это и даже учитывал меры, зависящие от друг друга, так что автоматизировать процесс вполне возможно. С учетом этих двух моментов я не вижу причин, по которым вам все равно следует использовать переменные для выражений в Qlik Sense.

Все еще не убедил?

Проблема также в том, как переменные хранятся, когда вы не удаляете их физически. Одним из стандартных предварительных тестов в QlikView было удаление всех переменных, запуск сценария (который должен воссоздать все необходимые переменные) и проверка того, что все в порядке. Часто я обнаруживал проблемы, когда старые переменные удалялись из сценария или контрольного листа, но не удалялись из приложения, и это становилось ошибкой в вычислениях или ставало причиной некорректной функциональности. Не используя API в QlikSense, вы должны вручную удалить все переменные (это может занять много времени). По этой самой причине я бы использовал переменные только там, где это абсолютно необходимо, поддерживая абсолютный минимум списка.

• Учебный центр по технологиям анализа данных и BI: расписание/запись на учебные курсы, тестирование разработчиков — https://education.biconsult.ru/
• Присоединяйтесь к QUBIC – сообщество профессионалов в области BI! Наши страницы в соц.сетях – расписание учебных курсов, бесплатные учебные материалы, анонсы мероприятий: https://vk.com/club165575964 и https://www.facebook.com/qubicspb
• Неофициальный форум разработчиков QlikView & Qlik Sense Russian forum
• Канал на Youtube – много обучающих видео и записи вебинаров
• Готовые решения “Конструктор финансовой отчетности” и “Анализ продаж”