Подключение в источники данных SAP HANA с помощью DirectQuery в Power BI

  • Статья

Вы можете подключаться к источникам данных SAP HANA напрямую с помощью DirectQuery. При подключении к SAP HANA существует два варианта:

  • Рассматривать SAP HANA как многомерный источник (по умолчанию): в этом случае поведение аналогично тому, когда Power BI подключается к другим многомерным источникам, таким как SAP Business Warehouse или Analysis Services. При подключении к SAP HANA с помощью этого параметра выбрано одно представление аналитики или вычисления, а также все меры, иерархии и атрибуты этого представления доступны в списке полей. При создании визуальных элементов агрегированные данные всегда извлекаются из SAP HANA. Этот метод рекомендуется использовать и используется по умолчанию для новых отчетов DirectQuery по протоколу SAP HANA.

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

Подход к подключению определяется глобальным средством, который устанавливается путем выбора параметров и параметров файла>, а затем> параметров DirectQuery, а затем выбора параметра "Рассматривать SAP HANA как реляционный источник", как показано на следующем рисунке.

Screenshot of the Options dialog, showing the DirectQuery options.

Возможность рассматривать SAP HANA как реляционные исходные элементы управления подходом, используемым для любого нового отчета с помощью DirectQuery через SAP HANA. Он не влияет на существующие подключения SAP HANA в текущем отчете, а также на подключениях в других отчетах, открытых. Поэтому если параметр в настоящее время не проверка, то при добавлении нового подключения к SAP HANA с помощью get Data это подключение делается для обработки SAP HANA как многомерного источника. Однако если открывается другой отчет, который также подключается к SAP HANA, этот отчет продолжает вести себя в соответствии с параметром, заданным во время его создания. Это означает, что все отчеты, подключающиеся к SAP HANA, созданные до февраля 2018 года, продолжают рассматривать SAP HANA как реляционный источник.

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

Рассматривать SAP HANA как многомерный источник (по умолчанию)

Все новые подключения к SAP HANA используют этот метод подключения по умолчанию, рассматривая SAP HANA как многомерный источник. Для обработки подключения к SAP HANA в качестве реляционного источника необходимо выбрать >параметры файла и параметры>, а затем проверка поле в разделе "Прямой запрос>" обрабатывает SAP HANA как реляционный источник.

При подключении к SAP HANA в качестве многомерного источника применяются следующие рекомендации.

  • В навигаторе получения данных можно выбрать одно представление SAP HANA. Невозможно выбрать отдельные меры или атрибуты. Запрос не определен во время подключения, который отличается от импорта данных или при использовании DirectQuery при обработке SAP HANA в качестве реляционного источника. Это также означает, что при выборе этого метода подключения невозможно напрямую использовать запрос SAP HANA SQL.

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

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

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

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

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

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

  • В SAP HANA атрибут можно определить для использования другого атрибута в качестве метки. Например, Product, с значениями 1, 23и т. д., может использовать ProductName, со значениямиBike, GlovesShirtи т. д. в качестве метки. В этом случае в списке полей отображается одно поле Product, значения которого — меткиBike, ShirtGlovesи т. д., но сортируются по и с уникальностью, определяемой ключевыми значениями 1, и 2т3. д. Кроме того, создается скрытый столбец Product.Key , разрешающий доступ к базовым значениям ключей при необходимости.

Все переменные, определенные в базовом представлении SAP HANA, отображаются во время подключения, а необходимые значения можно ввести. Эти значения можно изменить позже, выбрав "Преобразовать данные " на ленте, а затем изменить параметры в раскрывающемся меню.

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

Дополнительные ограничения моделирования

Другие основные ограничения моделирования при подключении к SAP HANA с помощью DirectQuery (рассматриваются как многомерный источник) являются следующими ограничениями:

  • Нет поддержки вычисляемых столбцов: возможность создания вычисляемых столбцов отключена. Этот факт также означает, что группирование и кластеризация, которые создают вычисляемые столбцы, недоступны.
  • Дополнительные ограничения для мер. Существуют и другие ограничения, введенные для выражений DAX, которые можно использовать в мерах, чтобы отразить уровень поддержки, предоставляемой SAP HANA.
  • Нет поддержки определения связей: только одно представление может запрашиваться в отчете, и таким образом не поддерживает определение связей.
  • Нет представления данных: в представлении данных обычно отображаются данные уровня детализации в таблицах. Учитывая характер источников OLAP, таких как SAP HANA, это представление недоступно для SAP HANA.
  • Исправлены сведения о столбцах и мерах: список столбцов и мер, которые отображаются в списке полей, исправлены базовым источником и не могут быть изменены. Например, невозможно удалить столбец или изменить его тип данных. Однако его можно переименовать.
  • Дополнительные ограничения в DAX: существуют другие ограничения daX, которые можно использовать в определениях мер, чтобы отразить ограничения в источнике. Например, нельзя использовать агрегатную функцию по таблице.

Дополнительные ограничения визуализации

Существуют ограничения в визуальных элементах при подключении к SAP HANA с помощью DirectQuery (рассматривать как многомерный источник):

  • Нет агрегирования столбцов: невозможно изменить агрегирование столбца в визуальном элементе и всегда не суммировать.

Определение SAP HANA в качестве реляционного источника

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

Начните с уточнения поведения реляционного источника, например SQL Server, когда запрос, определенный в get Data или Редактор Power Query, выполняет агрегирование. В следующем примере запрос, определенный в Редактор Power Query, возвращает среднюю цену по ProductID.

Diagram showing a query defined in Power Query Editor that returns the average price by Product ID.

Если данные импортируются в Power BI и используют DirectQuery, следующая ситуация приведет к следующему:

  • Данные импортируются на уровне агрегирования, определенного запросом, созданным в Редактор Power Query. Например, средняя цена по продукту. Этот факт приводит к таблице с двумя столбцами ProductID и AveragePrice , которые можно использовать в визуальных элементах.
  • В визуальном элементе выполняется любая последующая агрегирование, например Sum, Average, Min и другие, над импортированными данными. Например, в том числе AveragePrice на визуальном элементе использует статистическое выражение Sum по умолчанию и возвращает сумму по сравнению с AveragePrice для каждого ProductID, в этом примере 13,67. Это же относится к любой альтернативной статистической функции, например Min или Average, используемой в визуальном элементе. Например, среднее значениеAveragePrice возвращает среднее значение от 6,66, 4 и 3, которое равно 4,56, а не среднее значение price на шесть записей в базовой таблице, что составляет 5,17.

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

  • Учитывая тот же запрос, логически точно те же данные представлены на уровне отчетов, даже если данные не импортируются.

  • В визуальном элементе все последующие агрегаты, такие как Sum, Average и Min, снова выполняются над этой логической таблицей из запроса. И снова визуальный элемент, содержащий среднее значение AveragePrice, возвращает тот же 4,56.

Рассмотрим SAP HANA, когда подключение рассматривается как реляционный источник. Power BI может работать как с аналитическими представлениями, так и с представлениями вычислений в SAP HANA, оба из которых могут содержать меры. Тем не менее сегодня подход к SAP HANA следует тем же принципам, как описано ранее в этом разделе: запрос, определенный в методе Get Data или Редактор Power Query, определяет доступные данные, а затем любые последующие агрегаты в визуальном элементе над данными, и то же самое применяется для импорта и DirectQuery. Однако, учитывая характер SAP HANA, запрос, определенный в начальном диалоговом окне получения данных или Редактор Power Query, всегда является агрегированным запросом, и обычно включает меры, в которых фактические агрегаты, используемые представлением SAP HANA.

Эквивалентом предыдущего примера SQL Server является представление SAP HANA, содержащее идентификатор, ProductID, DepotID и меры, включая AveragePrice, определенное в представлении как среднее значение цены.

Если в интерфейсе получения данных выбранные значения были выбраны для ProductID и меры AveragePrice, то это определяет запрос по представлению, запрашивая эти статистические данные. В предыдущем примере для простоты используется псевдо SQL, который не соответствует точному синтаксису SAP HANA SQL. Затем все дальнейшие агрегаты, определенные в визуальном элементе, дополнительно агрегируют результаты такого запроса. Опять же, как описано ранее для SQL Server, этот результат применяется как для дела Import, так и DirectQuery. В случае DirectQuery запрос из Get Data или Редактор Power Query используется в подсементе в рамках одного запроса, отправляемого в SAP HANA, и поэтому на самом деле это не так, что все данные будут считываться до агрегирования дальше.

Все эти рекомендации и поведение требуют следующих важных аспектов при использовании DirectQuery для SAP HANA:

  • Обратите внимание на любое дополнительное агрегирование, выполняемое в визуальных элементах, всякий раз, когда мера в SAP HANA не является аддитивной, например не простой суммой, min или Max.

  • В get Data или Редактор Power Query необходимо включить только необходимые столбцы для получения необходимых данных, отражая тот факт, что результатом является запрос, который должен быть разумным запросом, который можно отправить в SAP HANA. Например, если выбраны десятки столбцов, с мыслью, что они могут потребоваться для последующих визуальных элементов, то даже для DirectQuery простой визуальный элемент означает, что агрегатный запрос, используемый в подсети, содержит эти десятки столбцов, которые обычно выполняются плохо.

В следующем примере выбор пяти столбцов (CalendarQuarter, Color, LastName, ProductLine, SalesOrderNumber) в диалоговом окне "Получение данных" вместе с мерой OrderQuantity означает, что позже создание простого визуального элемента, содержащего min OrderQuantity, приводит к следующему SQL-запросу к SAP HANA. Затенение — это вложенный выбор, содержащий запрос из get Data/Редактор Power Query. Если этот вложенный выбор дает высокий результат карта inality, то результирующая производительность SAP HANA, скорее всего, будет плохой.

Screenshot of a query example, showing the SQL query to SAP HANA.

Из-за этого мы рекомендуем элементы, выбранные в разделе "Получить данные" или Редактор Power Query быть ограничены теми элементами, которые необходимы, в то время как по-прежнему приводят к разумному запросу к SAP HANA.

Рекомендации

Для обоих подходов к подключению к SAP HANA рекомендации по использованию DirectQuery также применяются к SAP HANA, особенно рекомендации, связанные с обеспечением хорошей производительности. Дополнительные сведения см . в статье Об использовании DirectQuery в Power BI.

Рекомендации и ограничения

В следующем списке описываются все функции SAP HANA, которые не поддерживаются полностью, или функции, которые работают по-разному при использовании Power BI.

  • Родительские дочерние иерархии: родительские дочерние иерархии не отображаются в Power BI. Это связано с тем, что Power BI обращается к SAP HANA с помощью интерфейса SQL, а родительские дочерние иерархии не могут быть полностью доступны с помощью SQL.
  • Другие метаданные иерархии: базовая структура иерархий отображается в Power BI, однако некоторые метаданные иерархии, такие как управление поведением неровных иерархий, не влияют. Опять же, это связано с ограничениями, введенными интерфейсом SQL.
  • Подключение ion с помощью SSL: Вы можете подключаться с помощью импорта и многомерного использования TLS, но не удается подключиться к экземплярам SAP HANA, настроенным для использования TLS для реляционного соединителя.
  • Поддержка представлений атрибутов: Power BI может подключаться к представлениям аналитики и вычислений, но не может напрямую подключаться к представлениям атрибутов.
  • Поддержка объектов каталога: Power BI не может подключиться к объектам каталога.
  • Измените переменные после публикации: вы не можете изменить значения для любых переменных SAP HANA непосредственно в служба Power BI после публикации отчета.

Известные проблемы

В следующем списке описываются все известные проблемы при подключении к SAP HANA (DirectQuery) с помощью Power BI.

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

  • Несколько столбцов Power BI из одного столбца SAP HANA: для некоторых представлений вычислений, где столбец SAP HANA используется в нескольких иерархиях, SAP HANA предоставляет столбец в виде двух отдельных атрибутов. Этот подход приводит к созданию двух столбцов в Power BI. Однако эти столбцы скрыты по умолчанию, и все запросы, связанные с иерархиями, или столбцы напрямую ведут себя правильно.

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

Дополнительные сведения о DirectQuery проверка следующих ресурсов: