Поделиться через

Руководство по получению данных для отчетов с разбивкой на страницы

  • Статья

Эта статья предназначена для разработки отчетов Power BI с разбивкой на страницы. Она предоставляет рекомендации по разработке эффективного и эффективного извлечения данных.

Типы источников данных

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

Если можно выбрать тип источника данных (возможно, в новом проекте), рекомендуется использовать облачные источники данных. Отчеты с разбивкой на страницы могут подключаться с меньшей задержкой сети, особенно если источники данных находятся в том же регионе, что и клиент Power BI. Кроме того, можно подключиться к этим источникам с помощью единого входа. Это означает, что удостоверение пользователя отчета может передаваться в источник данных, что позволяет применять разрешения на уровне строк для каждого пользователя. В настоящее время единый вход поддерживается только для локальных источников данных SQL Server и Oracle (см. поддерживаемые источники данных для отчетов Power BI с разбивкой на страницы).

Примечание.

Хотя в настоящее время невозможно подключиться к локальным базам данных с помощью единого входа, вы по-прежнему можете применить разрешения на уровне строк. Это делается путем передачи встроенного поля UserID в параметр запроса набора данных. Источник данных должен хранить значения имени участника-пользователя (UPN), чтобы правильно фильтровать результаты запроса.

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

Реляционные источники данных

Как правило, реляционные источники данных хорошо подходят для отчетов по рабочему стилю, таких как счета по продажам. Они также подходят для отчетов, которые должны извлекать очень большие наборы данных (более 10 000 строк). Реляционные источники данных также могут определять хранимые процедуры, которые могут выполняться наборами данных отчета. Хранимые процедуры предоставляют несколько преимуществ:

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

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

Источники аналитических данных

Источники аналитических данных , также известные как модели данных или просто модели, хорошо подходят как для операционных, так и аналитических отчетов, и могут обеспечить быстрые суммированные результаты запросов даже по очень большим объемам данных. Меры модели и ключевые показатели эффективности могут инкапсулировать сложные бизнес-правила для достижения суммирования данных. Однако эти источники данных не подходят для отчетов, которые должны получать очень большие объемы данных (более 10 000 строк).

В Power BI построитель отчетов у вас есть два конструктора запросов: конструктор запросов DAX служб Analysis Services и конструктор многомерных выражений служб Analysis Services. Эти конструкторы можно использовать для источников данных семантической модели Power BI или любой модели SQL Server Analysis Services или azure Analysis Services — табличной или многомерной.

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

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

  • Определите вычисляемые элементы на уровне запроса (в многомерных выражениях).
  • Настройте регионы данных для запроса агрегатов сервера в группах , не относящихся к деталям. Если отчету необходимо представить сводки полу-или неаддитивных мер (например, вычислений аналитики времени или отдельных счетчиков), скорее всего, будет эффективнее использовать статистические данные сервера, чем для получения строк с низкоуровневой детализацией и сводных данных отчета.

Размер результата запроса

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

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

Поля на основе выражений

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

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

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

  • Возможно, ваш источник данных оптимизирован для более эффективной оценки выражения, чем Power BI (особенно это касается реляционных баз данных).
  • Производительность отчета улучшается, так как для Power BI не требуется материализовать вычисляемые поля перед отрисовкой отчета. Вычисляемые поля могут заметно увеличить время отрисовки отчета, когда наборы данных извлекают большое количество строк.

Имена полей

При создании набора данных его поля автоматически именуются столбцами запроса. Это возможно, эти имена не являются понятными или интуитивно понятными. Также возможно, что имена столбцов исходного запроса содержат символы, запрещенные в идентификаторах объектов языка определения отчетов (RDL) (например, пробелы и символы). В этом случае запрещенные символы заменяются символом подчеркивания (_).

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

Фильтр и параметр

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

  • Фильтр набора данных, в этом случае значения параметров отчета используются для фильтрации данных, уже извлеченных набором данных.
  • Параметр набора данных, в котором значения параметров отчета внедряются в собственный запрос, отправленный в источник данных.

Примечание.

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

Рассмотрим пример отчета о продажах с одним параметром отчета для фильтрации отчета по одному году. Набор данных получает продажи на протяжении всех лет. Это происходит, так как параметр отчета сопоставляется с фильтрами набора данных. В отчете отображаются данные за запрошенный год, который является подмножеством данных набора данных. Когда пользователь отчета изменяет параметр отчета в другой год, а затем просматривает отчет, Power BI не требует получения исходных данных. Вместо этого он применяет другой фильтр к уже кэшированному набору данных. После кэширования набора данных фильтрация может быть очень быстрой.

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

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

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

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

Источники данных, отличные от собственного кода

Если необходимо разработать отчеты с разбивкой на страницы на основе источников данных, которые изначально не поддерживаются отчетами с разбивкой на страницы, сначала следует разработать модель данных в Power BI Desktop. Таким образом, можно подключиться к сотням источников данных, поддерживаемых Power BI. После публикации в служба Power BI можно разработать отчет с разбивкой на страницы, который подключается к семантической модели Power BI.

Интеграция данных

Если необходимо объединить данные из нескольких источников данных, у вас есть два варианта:

  • Объединение наборов данных отчета. Если источники данных изначально поддерживаются отчетами с разбивкой на страницы, можно создать вычисляемые поля, использующие функции Lookup или LookupSet построитель отчетов.
  • Разработка модели Power BI Desktop: скорее всего, эффективнее разрабатывать модель данных в Power BI Desktop. Power Query можно использовать для объединения запросов на основе любого поддерживаемого источника данных. После публикации в служба Power BI можно разработать отчет с разбивкой на страницы, который подключается к семантической модели Power BI.

Задержка в сети

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

Совет

Чтобы определить расположение клиента, см. статью "Где находится мой клиент Power BI"?

Когда пользователи из клиента получают доступ к служба Power BI, их запросы всегда направляются в этот регион. По мере того как запросы достигают служба Power BI, служба может отправлять дополнительные запросы( например, в базовый источник данных или шлюз данных), которые также подвергаются задержке в сети. Как правило, чтобы свести к минимуму влияние задержки в сети, старайтесь сохранить источники данных, шлюзы и емкость Power BI как можно ближе. Предпочтительно, они находятся в одном регионе. Если задержка в сети является проблемой, попробуйте найти шлюзы и источники данных ближе к емкости Power BI, разместив их в облачных виртуальных машинах.

Сложные типы данных SQL Server

Так как SQL Server является локальным источником данных, Power BI должен подключаться через шлюз. Однако шлюз не поддерживает получение данных для сложных типов данных. Сложные типы данных включают встроенные типы, такие как geometry и GEOGRAPHY пространственных данных, и иерархия. Они также могут включать определяемые пользователем типы, реализованные через класс сборки в среде CLR майкрософт платформа .NET Framework.

Для построения пространственных данных и аналитики в визуализации карты требуются пространственные данные SQL Server. Поэтому невозможно работать с визуализацией карты, когда SQL Server является источником данных. Чтобы быть понятным, он будет работать, если источник данных База данных SQL Azure, так как Power BI не подключается через шлюз.

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

  • Возможно, данные изображения также можно получить из источника данных (если они уже хранятся в таблице).
  • При хранении изображений на веб-сервере можно использовать динамическое выражение для создания пути URL-адреса изображения.

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

Получение избыточных данных

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

Удаленные поля запроса

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

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

Неиспользуемые наборы данных

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

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

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