Разделение отчетов от моделей в 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: ссылки на столбцы и меры.

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

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

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

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

Связанный контент

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