Разделение отчетов от моделей в Power BI Desktop

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Просмотрите связанное содержимое для семантической модели в служба Power BI.
• Просмотрите представление происхождения данных в служба Power BI.

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

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

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

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

• Подключение семантическую модель в служба Power BI из Power BI Desktop
• Просмотр связанного содержимого в служба Power BI
• Data lineage (Происхождение данных)
• Вопросы? Задайте их в сообществе Power BI.
• Есть предложения? Участие в разработке идей по улучшению Power BI