Отделение отчетов от моделей в Power BI Desktop

При создании нового решения Power BI Desktop одной из первых задач, которые необходимо выполнить, является "получение данных". Получение данных может привести к двум различным результатам. Это может:

  • Создайте динамическое подключение к уже опубликованной модели, которая может быть семантической моделью Power BI или моделью удаленных служб Analysis Services.
  • Начните разработку новой модели, которая может быть либо импортом, либо DirectQuery, либо составной моделью.

Эта статья посвящена второму сценарию. В нем содержатся рекомендации о том, следует ли объединить отчет и модель в один файл Power BI Desktop.

Одно файловое решение

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

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

Отдельные файлы отчетов

Важно разделить разработку моделей и отчетов в отдельные файлы Power BI Desktop, когда:

  • Моделиторы данных и авторы отчетов являются разными людьми.
  • Понятно, что модель будет источником для нескольких отчетов, сейчас или в будущем.

Существует три PBIX-файла. Первый содержит только модель. Остальные два содержат только отчеты, и они находятся в живом подключении к модели, размещенной в службе Power BI. Отчеты разрабатываются различными людьми.

Моделиаторы данных по-прежнему могут использовать опыт разработки отчетов Power BI Desktop для тестирования и проверки своих моделей. Однако сразу после публикации файла в служба Power BI они должны удалить отчет из рабочей области. И они должны помнить, чтобы удалить отчет каждый раз, когда они повторно публикуют и перезаписывают семантику модели.

Сохранение интерфейса модели

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

Таким образом, тщательно управляйте изменениями модели. Если это возможно, избежать следующих изменений:

  • Переименование таблиц, столбцов, иерархий, уровней иерархии или мер.
  • Изменение типов данных столбцов.
  • Изменение выражений мер, чтобы они возвращали другой тип данных.
  • Перемещение измерений в другую главную таблицу. Это связано с тем, что перемещение меры может нарушить меры, привязанные к области действия отчета, которые полностью определяют меры, используя имя их исходной таблицы. Мы не рекомендуем писать выражения DAX, используя полностью квалифицированные имена мер. Дополнительные сведения см. в разделе DAX: ссылки на столбцы и меры.

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

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

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

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

Дополнительные сведения, связанные с этой статьей, см. в следующих ресурсах: