Новые возможности в Tableau 2020.2

Статья собрана из опубликованных статей Академии Аналитики. На понятном примере рассматриваем новую модель данных (в сравнении с предыдущей моделью), обсуждаем плюсы и минусы метрик (рассмотрим советы о том, как обезопасить данные) , а также рассмотрим пример как провести анализ "что-если" с помощью новой функции управления сетами.

Давайте подробнее рассмотрим некоторые из основных функций этого релиза.

В новом релизе Tableau 2020.2 усовершенствована модель данных Tableau и появились связи (relationships), которые позволяют легко анализировать данные из нескольких таблиц на разных уровнях детализации. Связи объединяют таблицы и агрегируют данные во время анализа, запрашивая данные на необходимом уровне детализации на основе полей и фильтров. Связи позволяют уверенно комбинировать таблицы, разрешая многие сценарии дублирования данных и гарантируя, что вы получите точные результаты, не полагаясь на вычисления LOD.

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

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

Метрики – это новый тип контента, который предлагает простой способ отслеживания ключевых показателей эффективности (KPI), которые вас интересуют больше всего. Метрики показывают агрегированную меру, такую как сумма продаж и измерение «дата», например дата заказа. Вы получите основные показатели ваших данных в удобном формате. Вы можете просматривать ваши KPI с нескольких дашбордов на одной площадке– их можно просматривать в Интернете или в дороге с помощью мобильного приложения Tableau.

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

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

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

Создать метрику легко. А поскольку метрики являются типом контента, который существует в проектах, то пользователи могут перемещать метрики между проектами и добавлять их в избранное.

Set control — это управляющий объект, с помощью которого пользователь (прямо на view / дашборде) может изменять (выбирать / снимать выбор) значения в данном сете. Прямая аналогия с простым фильтром. только фильтр фильтрует одну колонку (поле), а set control «фильтрует» значения одного сета. Сет — это набор, состоящих из сочетаний уникальных значений одного или нескольких полей (колонок) типа Dimension.

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

Давайте рассмотрим пример. Ниже приводится описание средних цен на жилье в различных районах Лондона (разделены по принципу outcode, или почтового кода). Лондон построен концентрическими кругами, чем ближе к центру города, тем дороже. Чем дороже исходящий код, тем более оранжевый цвет. Давайте выберем outcodes E4, E5 и E6, расположенные недалеко от границы. Это означает, что мы усредняем их цены, а затем сравниваем их со средним значением остальных outcodes. Многие outcodes внезапно выглядят более красными — они выше в средней цене по сравнению с переферийными районами. Можно продолжать изменять элементы набора, чтобы сравнить различные группы outcodes.

В новой версии Tableau 2020.2 метрики (Metrics) позволяют просматривать KPI и тренды других показателей, получаемых из разных дашбордов, в простом и удобном формате, что, по сути, позволяет пользователям данных создавать свои собственные «дашборды» KPI, которые им нужны.

Мы поместили дашборд в кавычки, потому что имеем в виду не «дашборд Tableau» в традиционном смысле, а набор метрик на одном экране, который можно легко отслеживать, в том числе на мобильном устройстве.

На диаграмме ниже показана концепция работы метрик:

В приведенном выше примере метрики были созданы из четырех разных представлений, содержащихся в трех отдельных дашбордах. Теперь все эти показатели можно увидеть вместе на одной странице на Tableau Server.

Все метрики не обязательно хранить в одной папке — вы можете хранить каждую метрику в любом месте — однако, храня все метрики (или все связанные метрики) в одной папке, вы можете сделать удобный «инструмент», который вы видите выше на картинке.

Создание метрики

Создание метрики — это быстрый и простой процесс:

Подробности и скриншоты для каждого шага ниже:

Откройте дашборд или представление

Ниже — базовое представление, которое показывает среднее количество дней доставки товара по регионам:

Выберите отметку

Здесь выбрана отметка среднего количества дней отправки по регионам.

Важно отметить, что метрики основаны на уровне детализации выбранной отметки.

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

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

Можно выбрать любую точку на данном представлении.

Кликните на кнопку метрики

Выбрав отметку, кликните на кнопку «Metrics», которая находится на панели инструментов:

Добавьте имя, описание и сохраните метрику

Добавьте метрике имя и описание (необязательно).

Далее можно изменить место, где сохранить метрику. Кликните на кнопку «Change Location» откроется окно обзора (поиска) для навигации по папкам вашего проекта.

Далее кликните на кнопку «Create», чтобы сохранить метрику.

Откройте метрику

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

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

Поделитесь метрикой с коллегами

Метрики могут быть легко переданы другим пользователям на вашем Tableau Server:

Просмотреть все показатели в Grid View

Как упоминалось ранее, если сохранять несколько метрик в одной папке проекта на Tableau Server, как это сделали ниже в проекте под названием «My metrics», результатом при просмотре этого проекта будет дашборд KPI:

Просмотреть все показатели в списке

Если просматривать все показатели в списке, то не видна линия тренда, видны только самые последние значения, но за один раз можно увидеть больше метрик:

Метрики на мобильном телефоне

Возможность управлять пользовательским «дашбордом» KPI, который можно отслеживать в любое время в любом месте — это быстрый и удобный формат взаимодействия.

Мобильные метрики позволяют обновлять диапазон дат линии тренда (последние 4 недели, последние 12 недель и т. д.), а также устанавливать временные рамки сравнения (т.е. изменение по сравнению с прошлой неделей, прошлым месяцем и т. д.)

Возможность быстро переключаться между тремя представлениями метрики:

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

Вывод

Отзывы о пользовательском интерфейсе при взаимодействии с метриками действительно положительные; интерфейс простой и понятный. Этот новый функционал позволяет любому пользователю создавать собственные персонализированные представления KPI для мониторинга без необходимости «строить» все с нуля. И это никого не оставит равнодушным.

В новой версии Tableau 2020.2 появилась функция метрик, которую все очень ждали. Метрики позволяют легко отслеживать ключевые показатели эффективности в любом месте, в том числе и на мобильном устройстве. А также метрики очень легко и просто создавать. Когда вы используете Tableau Mobile для мониторинга метрик, можно обновлять диапазон дат линии тренда (последние 4 недели, последние 12 недель и т. д.), а также устанавливать временные рамки сравнения (т.е. изменение по сравнению с прошлой неделей, прошлым месяцем и т. д.)

Кто может создавать метрики?

На самом деле создание метрик — это процесс публикации, аналогичный сохранению результатов запроса данных для публикации на сервере или в рабочей книге. Автор метрики должен иметь следующее для создания метрик:

Что является источником для создания метрик?

Представление или пользовательское представление являются единственными источниками для создания метрик.Источник данных нельзя использовать для создания метрик.

Какая взаимосвязь между метриками и связанными представлениями?

Метрика создается из представления.Но, как только она уже создана, метрика становится больше похожа на «независимый» объект, у которого есть владелец и собственное разрешение доступа. Метрики останутся на сервере, когда представление будет удалено, но метрики больше не будут обновляться. Это очень похоже на взаимосвязь между опубликованным источником данных и связанной книгой.

Как работает разрешение доступа к метрикам?

Можно ли отключить метрики для сайта, проекта или рабочей книги?

Как обновляются метрики?

Как обновляются метрики? Ошибки при обновлении.

Информация об использовании (просмотре) метрик

Можно ли изменить метрики?

Этот процесс не отличается от перезаписи рабочей книги или источников данных. Если вам нужна новая версия опубликованной метрики, вы можете заменить существующую, если у вас есть разрешение на перезапись. Доступ к метрике останется неизменным после ее замены новой версией. Если вы сохраните новую метрику под другим именем, это будет отдельная новая метрика.

Примечание: вы можете создать много метрик из одного представления, но вы не можете объединить два измерения одного представления в одну метрику. Метрики отражают только одну меру (измерение).

Выводы:

Мы не хотим лишить вас возможности использовать метрики. На самом деле наоборот можем настоятельно порекомендовать всем использовать метрики, ведь это очень удобно и эффективно.Но обязательно нужно убедиться, что администраторы, руководители проектов и издатели в полной мере осведомлены о проблеме безопасности данных. Эта проблема связана с возможностью предоставления доступа к метрикам создателями метрик другим пользователям, без ведома издателей (руководителей) представлений с помощью которых (из которых) были созданы метрики. А также хотим посоветовать вам установить необходимые элементы управления, чтобы избежать потенциального хаоса безопасности данных:)

Итак:Для очень важных и конфиденциальных данных поместите рабочие книги в отдельный проект, далее заблокируйте доступ к проекту и запретите возможность загрузки полных данных «Download Full Data».Для одной или нескольких конфиденциальных рабочих книг (если вы не можете заблокировать доступ к проекту), вы можете контролировать доступ на уровне рабочей книги, не предоставляя возможности загрузки полных данных «Download Full Data».

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

Предыдущая модель данных

При использовании предыдущей модели данных (до версии Tableau 2020.2), мы выбирали таблицы, а также указывали тип объединения, как именно объединить выбранные таблицы.

Например, вот простая модель данных, которая объединяет таблицы Order и People на основе поля Region.

Давайте посмотрим на SQL, который при этом выполняется:

select *

FROM [Orders]

INNER JOIN [People]

ON [Orders].[Region] = [People].[Region]

Любые визуализации, которые мы создаем в Tableau при объединении таблиц Order и People, всегда будут использовать этот базовый SQL, даже если мы не включаем поля из таблицы People.

Например, давайте создадим очень простую гистограмму, которая показывает объем продаж по клиентам. Это сгенерирует следующий SQL:

select [Customer Name], SUM([Sales])

FROM [Orders]

INNER JOIN [People]

ON [Orders].[Region] = [People].[Region]

GROUP BY [Customer Name]

Два поля, которые используются в нашей визуализации, а именно Customer Name и Sales берутся из таблицы Order, то есть мы не используем поля из таблицы People. Тем не менее, SQL, сгенерированный Tableau, все еще включает соединение с таблицей People.

Этот подход имеет несколько недостатков.

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

Во-вторых мы можем получить больше записей, чем нам действительно нужно. Чтобы продемонстрировать это, давайте рассмотрим вариант, в котором между нашими таблицами существует отношение «один ко многим» (one-to-many). Ниже, приведена альтернативная таблица данных Person с именем Person_Multiple:

Видно, что в этой таблице в каждом регионе есть два человека. Если использовать эту таблицу в нашей модели данных, то для нее будет выполнятся SQL, аналогичный описанному выше. Но так как в каждом регионе есть два человека, каждая запись в таблице Order будет дублироваться. Итак, мы получим 19 988 записей вместо 9 994 записей, которые находятся в таблице Order. А если речь идет о миллионных записях, можно представить к чему это может привести. Но эта разница в объеме данных является лишь частью проблемы — на дублирование данных также влияют агрегации.

Например, давайте снова создадим гистограмму, показывающую объемы продаж по клиентам. Выполняется почти тот же SQL (за исключением использования People_Multiple вместо People), но из-за дублирования записей наши итоговые агрегаты продаж удваиваются. Самым типичным решением этой проблемы является использование вычислений LOD (Level-of-Detail). К сожалению, вычисления LOD немного сложны и не всегда доступны для новых пользователей Tableau. Кроме того, некоторые пользователи могут даже не осознавать, что их объединение привело к дублированию данных, и, следовательно, они не знают, что им нужно решить эту проблему.

Примечание: есть другой способ решения проблемы — параметр «Assume Referential Integrity». Когда вы используете этот параметр, Tableau автоматически включает объединенную таблицу в запрос, только если на нее специально ссылаются поля в вашей визуализации. Это, конечно, приведет к более эффективному SQL. Но нужно также быть осторожными — если вы выберете эту функцию, но ваша база данных не будет иметь «ссылочной целостности», это может привести к неточным результатам.

Итак, три выявленные проблемы при использовании предыдущей модели данных:

1) Слишком сложный SQL — ненужное чрезмерное усложнение нашего SQL, которое влияет на производительность.

2) Дублированные записи — больше записей, чем нам нужно.

3) Требования LOD — необходимость использовать вычисления LOD для устранения дублирования данных в агрегатах.

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

Новая модель данных

Давайте рассмотрим новую модель данных в новой версии Tableau 2020.2. Использование «связей» (Relationships) означает, что Tableau будет генерировать уникальный SQL для каждого создаваемого вами представления (визуализации), который больше не будет включать все таблицы в вашей модели данных. Вместо этого он анализирует поля, которые используются в вашем представлении, и создает SQL, предназначенный для получения только тех данных, которые вам действительно нужны.

Ниже приведена модель данных с использованием «связей». Обратите внимание, что нет диаграммы Венна, которая показывает тип соединения. Это из-за того, что нам больше не нужно указывать тип соединения. Мы просто определяем связь между двумя таблицами — в данном случае, по полю Region. Но на данный момент эти таблицы остаются независимыми. Tableau не создает базовый SQL для использования в рабочей книге, как в старой модели данных. Мы просто устанавливаем связь между таблицами, которые будут использоваться.

Давайте еще раз построим нашу гистограмму объема продаж по клиентам. Используя новую модель данных, наш SQL будет выглядеть так:

select [Customer Name], SUM([Sales])

FROM [Orders]

GROUP BY [Customer Name]

Tableau автоматически определяет, что ни одно из полей People не используется в этом представлении, и поэтому исключил его из SQL. Это понятие, которое в Tableau называется «join culling» — в основном процесс, с помощью которого механизм обработки данных удаляет ненужные объединения.

Но что произойдет, если мы будем использовать поле из таблицы People в нашем представлении? Например, что если мы отразим записи только для Anna Andreadi (таблица People, столбец Person)? Это сгенерирует следующий SQL:

select [Customer Name], SUM([Sales])

FROM [Orders]

INNER JOIN [People]

ON [Orders].[Region] = [People].[Region]

WHERE [Person] = 'Anna Andreadi'

GROUP BY [Customer Name]

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

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

Но как новая модель данных влияет на наши две другие проблемы — дублирование записей и требование LOD, — которые вызваны отношениями один ко многим (one-to-many)?

Предыдущая модель данных объединяет таблицы, а только потом сохраняет данные, в новой модели данные таблиц хранятся вне зависимости от объединения. Таким образом, дублирование данных не является проблемой с точки зрения объема данных. Но это может быть проблемой, когда дело доходит до агрегации. Чтобы понять это, давайте изменим нашу модель данных, для этого будем использовать таблицу People_Multiple вместо People:

Теперь давайте снова построим нашу простую гистограмму объем продаж по клиентам. Когда мы сделаем это, наш SQL будет выглядеть так:

select [Customer Name], SUM([Sales])

FROM [Orders]

GROUP BY [Customer Name]

Итак, поскольку представление не содержит никаких полей из таблицы People_Multiple, Tableau автоматически отбирает соединения. И преимущество этого простого SQL в том, что SUM (Sales) не будет дублироваться и это даст нам фактическое значение без необходимости вычисления LOD.

Но что произойдет при использовании поля из таблицы People_Multiple? Добавим фильтр на Person = 'Central Person 1'. Наш SQL при этом будет выглядеть так:

select [Customer Name], SUM([Sales])

FROM [Orders]

INNER JOIN (

select [Orders].[Region]

FROM [Orders]

INNER JOIN [People_Multiple]

ON [Orders].[Region] = [People_Multiple].[Region]

WHERE [Person] = 'Central Person 1'

GROUP BY [Orders].[Region]

) AS [Table 1]

ON [Orders].[Region] = [Table 1].[Region]

GROUP BY [Customer Name]

Видно, что этот запрос немного сложнее, чем любой, который мы рассматривали выше. Tableau автоматически определил, что в нашей таблице есть отношение один ко многим (one-to-many), поэтому Tableau избегает прямого соединения между таблицами Orders и People_Multiple, так как это может привести к дублированию записей. Вместо этого Tableau генерирует следующий подзапрос:

select [Orders].[Region]

FROM [Orders]

INNER JOIN [People_Multiple]

ON [Orders].[Region] = [People_Multiple].[Region]

WHERE [Person] = 'Central Person 1'

GROUP BY [Orders].[Region]

Этот запрос объединяет Orders и People_Multiple, избирая только Region — поле, на котором строятся наши связи с таблицами. Результатом этого конкретного SQL является один столбец и строка:

Затем он присоединяет это обратно к таблице Orders и подводит итоги продаж. Поскольку SQL избегает непосредственного объединения двух таблиц, мы не получаем дублирования данных, и агрегация имеет точное значение без необходимости выполнять сложные вычисления LOD.

Вывод: мы рассмотрели новую модель данны, и очень надеемся, что теперь вы лучше понимаете, как она работает, а также чем она отличается от предыдущей модели данных и какие проблемы решает. Не заблуждайтесь — это особенность игры. Таким образом новая модель данных устраняет ряд общих проблем, в том числе проблему, которая возникает при работе с отношениями один-ко-многим (one-to-many).

Это популярная бизнес-тактика для визуализации различий между фактическими или ожидаемыми результатами и нестандартным сценарием (то есть, что произойдет, если мы сможем увеличить продажи на 10%).

Анализ "что — если" стал намного проще с введением функции Set Control в новой версии Tableau 2020.2. Теперь сценарий можно применить к одному или нескольким элементам измерения, и вы можете иметь несколько сценариев в одном представлении. Сегодня мы рассмотрим, как использовать функцию Set Control в Tableau для создания более динамичного и удобного сценария планирования.

К концу этой статьи вы сможете самостоятельно создать представление и провести анализ "что — если" для положительного и отрицательного сценария на одном и том же представлении.

Для этого анализа вы можете применить положительные сценарии «что — если» к одной группе элементов измерения и отрицательные сценарии «что если» ко второй группе элементов измерения.Для начала нужно создать пустой сет для каждого сценария (в данном случае положительные и отрицательные изменения). Мы используем измерение Sub-Category из данных Sample — Superstore, итак, самый простой способ создать пустой сет — кликнуть правой кнопкой мыши на поле Sub-Category в области данных, навести курсор мыши на «Create» и выбрать «Set».

Откроется диалоговое окно, в котором вы можете дать имя сету и кликнуть «ОК», чтобы закрыть окно.

Повторите этот шаг для второго набора элементов измерения Sub-Category.

Итак, мы создали два сета из поля Sub-Category и назвали их: Positive Set, Negative Set.

Далее нужно создать параметр для управления значениями сценария, применяемыми к каждому из этих двух сетов. Чтобы создать параметр кликните правой кнопкой мыши по нужному сету (Positive Set, Negative Set) и кликните на Create, далее выберете Parametr.

Далее появится диалоговое окно.

Для Positive Set создадим параметр с именем Positive Scenarios с типом данных Integer и укажем диапазон значений от 0 до 100 с шагом 5. Это в конечном итоге будет соответствовать процентному увеличению показателя продаж от 0 до 100 процентов.

Для Negative Set создадим параметр с именем Negative Scenarios с типом данных Integer и укажем диапазон значений от -100 до 0, также с шагом 5.Это в конечном итоге будет соответствовать процентному снижению показателя продаж, вплоть до потери 100% продаж.

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

Теперь для того, чтобы начать использовать эти несколько сценариев "что — если" одновременно, нужно создать вычисляемое поле.

Для этого кликаем правой кнопкой мыши по полю Sales выбираем Create и кликаем на Calculated Field.

Создадим вычисляемое поле, назовем его What-If Sales. Для двух созданных сетов, будем следующую формулу:

IF [Positive Set] THEN [Sales]*(1+([Positive Scenarios]/100))

elseif [Negative Set] THEN [Sales]*(1+([Negative Scenarios]/100))

ELSE [Sales]

END

Примечание: если вы захотите отображать значения параметров в процентах, нужно удалить «/ 100» из первых двух строк.

Эта формула позволит нам визуализировать несколько сценариев на одном представлении, но нужно обратить внимание, что каждый элемент измерения может быть классифицирован только один раз. Например, мы не можем одновременно повышать и понижать продажи для одной подкатегории. Логика IF / THEN в этом вычисляемом поле идет по порядку сверху вниз, поэтому, если бы подкатегория была и в Positive Set, и в Negative Set, она была бы классифицирована как положительный сценарий, прежде чем дошла бы до второй строки — негативного сценария.

Чтобы убедиться, что это работает правильно, давайте создадим гистограмму из двух столбцов с исходными продажами слева и созданными продажами с условием "что — если" справа. Для этого перетаскиваем пилюлю Sales и What — If Sales на полку Columns, и перетаскиваем пилюлю Sub-Category на полку Rows.

Вот что у нас получилось.

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

Чтобы отобразить элемент управления параметром, кликните правой кнопкой мыши на каждый параметр (Positive scenarios и Negative Scenarios) и выберите «Show Parameter».

Чтобы отобразить элемент управления сетом (set control), кликните правой кнопкой мыши на сеты (Positive Set и Negative Set) и кликните «Show Set».

Вот что у нас получилось:

Теперь вы можете позволить себе и своим пользователям решать, что будет добавлено в сет, так же, как если бы вы использовали обычный дискретный фильтр!

Предположим, что для наших сценариев нынешние условия увеличат продажи для наших подкатегорий Bookcases, Envelopes, Machines и Storage на 25% при одновременном сокращении продаж наших подкатегорий Accessories, Binders, Copiers, Supplies и Tables на 40%.

Для этого выберем из списка Positive Set элементы Bookcases, Envelopes, Machines и Storage и укажем значение 25 для параметра Positive Scenarios.Также выберем из списка Negative Set элементы Accessories, Binders, Copiers, Supplies и Tables и укажем значение -40 для параметра Negative Scenarios.

Вот что у нас получилось:

Видим изменения в правом столбце. Теперь, когда мы видим, что это работает, есть несколько интересных вариантов обыграть наше представление. Сначала создадим вычисляемое поле, которое окрашивает элементы измерения в зависимости от того, включены ли они в сценарий "что — если". Для этого кликаем правой кнопкой мыши по пилюле What-If Sales и выбираем Create далее кликаем на Calculated Field. Назовем вычисляемое поле What-If Color, и введем следующую формулу:

IF [Positive Set] THEN «Positive Scenarios»

elseif [Negative Set] THEN «Negative Scenarios»

ELSE «Not Included»

END

Далее перетаскиваем пилюлю What-If Color на карточку цвета Color. Вот что у нас получилось:

Теперь мы знаем, какие элементы измерения включены в сценарии "что — если«. Чтобы лучше интегрировать значения »что — если" с фактическими значениями, давайте проделаем следующие настройки:

- Кликаем правой кнопкой мыши на пилюлю SUM (What-If Sales) которая находится на полке Columns и выбираем Dual Axis.

- Изменить тип метки для этого кликаем правой кнопкой мыши на пилюлю SUM (Sales) которая находится на полке Columns, далее кликаем на Mark Type и выбираем Bar. Также для SUM (What-If Sales) выбираем Gantt Bar.

- Перетаскиваем пилюлю What-If Sales на карточку Size, чтобы регулировать размер Gantt Bar

- Далее нужно синхронизировать оси, для этого кликаем правой кнопкой мыши на любую ось и выбираем Synchronize Axis

- Теперь создадим вычисляемое поле для What-If Sales, кликаем правой кнопкой мыши по пилюле What-If Sales далее выбираем Create, далее кликаем на Calculated Field и вводим следующую формулу: SUM([Sales]) – SUM([What-If Sales]) — назовем вычисляемое поле Calculation1 (по умолчанию). Далее перетаскиваем Calculation1 на карточку Size

Итак, вот что у нас получилось:

Мы только что создали одну визуализацию, содержащую несколько сценариев "что — если", которые наши пользователи могут легко обновить на лету, используя новые элементы управления Tableau. Мы использовали данную гистограмму для простоты иллюстрации и проверки качества, но эти сценарии можно применять ко всей книге на любом типе диаграммы.