Работа с составными моделями в Power BI Desktop

Ранее в Power BI Desktop при использовании DirectQuery в отчете никакие другие подключения к данным, будь то DirectQuery или импорт, были разрешены для этого отчета. При использовании составных моделей это ограничение удаляется. Отчет может легко включать подключения к данным из нескольких directQuery или импортировать подключение к данным в любом сочетании.

Возможности составных моделей в Power BI Desktop состоят из трех связанных функций:

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

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

• Режим хранения. Теперь можно указать, какие визуальные элементы запрашивают внутренние источники данных. Эта функция помогает повысить производительность и уменьшить нагрузку на внутренние компоненты. Ранее даже простые визуальные элементы, такие как срезы, инициируемые запросы к внутренним источникам. Дополнительные сведения см. в разделе "Управление режимом хранения" в Power BI Desktop.

Использование составных моделей

Составные модели позволяют подключаться к различным типам источников данных при использовании Power BI Desktop или служба Power BI. Эти подключения к данным можно сделать несколькими способами:

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

При использовании DirectQuery составные модели позволяют создать модель Power BI, например один PBIX-файл Power BI Desktop, который выполняет одно или оба из следующих действий:

• Объединяет данные из одного или нескольких источников DirectQuery.
• Объединяет данные из источников DirectQuery и импортирует данные.

Например, с помощью составных моделей можно создать модель, которая объединяет следующие типы данных:

• Данные о продажах из корпоративного хранилища данных.
• Целевые данные продаж из базы данных SQL Server отдела.
• Данные, импортированные из электронной таблицы.

Модель, которая объединяет данные из нескольких источников DirectQuery или объединяет DirectQuery с данными импорта, называется составной моделью.

Вы можете создавать связи между таблицами так же, как всегда, даже если эти таблицы приходят из разных источников. Любые связи, которые являются перекрестными источниками, создаются с кратностью "многие ко многим", независимо от их фактической кратности. Их можно изменить на "один ко многим", "многие на один" или "один на один". Независимо от заданного количества связей между источниками отличается поведение. Функции анализа данных (DAX) нельзя использовать для получения значений на стороне one many с стороны. Вы также можете увидеть влияние на производительность и связи "многие ко многим" в одном источнике.

Пример составной модели

Пример составной модели рассмотрим отчет, который подключается к корпоративному хранилищу данных в SQL Server с помощью DirectQuery. В этом случае хранилище данных содержит данные о продажах по стране, кварталу и велосипеду (продукту ), как показано на следующем рисунке:

На этом этапе можно создать простые визуальные элементы с помощью полей из этого источника. На следующем рисунке показан общий объем продаж по ProductName в течение выбранного квартала.

Но что делать, если у вас есть данные в электронной таблице Excel о диспетчере продуктов, назначенном каждому продукту, а также приоритете маркетинга? Если вы хотите просмотреть объем продаж по Product Manager, возможно, не удастся добавить эти локальные данные в корпоративное хранилище данных. Или это может занять несколько месяцев в лучшем случае.

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

• Некоторые сочетания правил безопасности, применяемых в базовом источнике.
• Необходимо иметь возможность просматривать последние данные.
• Более простой масштаб данных.

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

В списке полей можно увидеть две таблицы: исходную таблицу Bike из SQL Server и новую таблицу ProductManagers . Новая таблица содержит данные, импортированные из Excel.

Аналогичным образом в представлении связей в Power BI Desktop теперь отображается другая таблица с именем ProductManagers.

Теперь необходимо связать эти таблицы с другими таблицами в модели. Как всегда, мы создадим связь между таблицей Bike из SQL Server и импортированной таблицей ProductManagers . То есть связь между Bike[ProductName] и ProductManagers[ProductName]. Как упоминалось ранее, все связи, которые проходят по умолчанию для кратности "многие ко многим".

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

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

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

Как и ранее, мы можем создавать связи между новой таблицей и другими таблицами в модели. Затем мы можем создать визуальные элементы, которые объединяют данные таблицы. Давайте рассмотрим представление "Связи" , где мы установили новые отношения:

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

Настройка режима хранения

Каждая таблица в составной модели имеет режим хранения, указывающий, основана ли таблица на directQuery или импорте. Режим хранения можно просмотреть и изменить на панели свойств . Чтобы отобразить режим хранения, щелкните правой кнопкой мыши таблицу в списке полей и выберите пункт "Свойства". На следующем рисунке показан режим хранения для таблицы SalesTargets .

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

Для любого файла Power BI Desktop ( PBIX-файла ), содержащего некоторые таблицы из DirectQuery и некоторых таблиц импорта, в строке состояния отображается режим хранения с именем Mixed. Этот термин можно выбрать в строке состояния и легко переключить все таблицы на импорт.

Дополнительные сведения о режиме хранения см. в разделе "Управление режимом хранения" в Power BI Desktop.

вычисляемые таблицы;

Вы можете добавить вычисляемые таблицы в модель в Power BI Desktop, использующую DirectQuery. Выражения анализа данных (DAX), определяющие вычисляемую таблицу, могут ссылаться на импортированные или таблицы DirectQuery или сочетание двух.

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

Последствия для безопасности

Составные модели имеют некоторые последствия для безопасности. Запрос, отправленный одному источнику данных, может включать значения данных, полученные из другого источника. В предыдущем примере визуальный элемент, показывающий (объем продаж) Product Manager , отправляет SQL-запрос в реляционную базу данных sales. Этот SQL-запрос может содержать имена менеджеров по продуктам и связанных с ними продуктов.

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

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

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

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

Кроме того, если автор добавляет table1 из model A в составную модель (давайте называем ее Model C для справки), то пользователь, просматривающий отчет, построенный на модели C, может запрашивать любую таблицу в модели A, которая не защищена RLS уровня строк.

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

Влияние на производительность

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

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

• Исходный запрос, содержащий большое количество литеральных значений: например, визуальный элемент, который запрашивает общую сумму продаж для набора выбранных менеджеров по продуктам, сначала потребуется найти, какие продукты управляются этими менеджерами по продуктам. Эта последовательность должна произойти, прежде чем визуальный элемент отправляет SQL-запрос, содержащий все идентификаторы продуктов в предложении WHERE .

• Исходный запрос, который запрашивает на более низком уровне детализации, при этом данные позже агрегируются локально: по мере того как количество продуктов, удовлетворяющих критериям фильтра в Product Manager, становится неэффективным или неуместным, чтобы включить все продукты в WHERE предложение. Вместо этого можно запрашивать реляционный источник на более низком уровне продуктов , а затем агрегировать результаты локально. Если кратность продуктов превышает ограничение в 1 млн, запрос завершается ошибкой.

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

  Визуальный элемент, который запрашивает отдельный счетчик CustomerAccountNumber из таблицы SQL Server, импортированный из электронной таблицы, потребуется передать сведения из таблицы "Диспетчеры продуктов" в запросе, отправленном в SQL Server. Например, по сравнению с другими источниками Redshift это действие невозможно. Вместо этого в диспетчере продаж будет отправлен один SQL-запрос, до некоторого практического ограничения, в то время как запрос завершится ошибкой.

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

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

Исходные группы

Исходная группа — это коллекция элементов, таких как таблицы и связи, из источника DirectQuery или всех источников импорта, участвующих в модели данных. Составная модель состоит из одной или нескольких исходных групп. Рассмотрим следующие примеры:

• Составная модель, которая подключается к семантической модели Power BI с именем Sales и обогащает семантику, добавив меру Sales YTD , которая недоступна в исходной семантической модели. Эта модель состоит из одной исходной группы.
• Составная модель, которая объединяет данные путем импорта таблицы из листа Excel с именем Targets и CSV-файла с именем "Регионы" и подключения DirectQuery к семантической модели Power BI с именем Sales. В этом случае существует две исходные группы, как показано на следующем рисунке:
  • Первая исходная группа содержит таблицы из листа "Целевые объекты Excel" и CSV-файл "Регионы ".
  • Вторая исходная группа содержит элементы из семантической модели Sales Power BI.

Если вы добавили другое подключение DirectQuery к другому источнику, например подключение DirectQuery к базе данных SQL Server с именем Inventory, элементы из этого источника добавляются в другую исходную группу:

Исходные группы и связи

В составной модели существует два типа связей:

• Внутри исходных связей групп. Эти связи связывают элементы в исходной группе вместе. Эти отношения всегда являются регулярными отношениями, если они не многие ко многим, в этом случае они ограничены.
• Перекрестные связи между исходными группами. Эти связи начинаются в одной исходной группе и заканчиваются другой исходной группой. Эти связи всегда ограничены.

Узнайте больше о различиях между регулярными и ограниченными отношениями и их воздействием.

Например, на следующем изображении мы добавили три связи между исходными группами, связанные с таблицами между различными исходными группами вместе:

Локально и удаленно

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

[Average Inventory Count] = Average(Inventory[Inventory Count])

Группы вычислений, запрос и оценка мер

Группы вычислений позволяют уменьшить количество избыточных мер и группировку общих выражений мер. Типичные варианты использования — это вычисления аналитики времени, в которых вы хотите переключиться с фактических на актуальные, квартальные или годовые вычисления. При работе с составными моделями важно учитывать взаимодействие между группами вычислений и указывать, относится ли мера только к элементам из одной удаленной исходной группы. Если мера относится только к элементам из одной удаленной исходной группы, а удаленная модель определяет группу вычислений, которая влияет на меру, применяется эта группа вычислений, даже если мера была определена в удаленной модели или в локальной модели. Однако если мера не относится к элементам из одной удаленной группы источников, но относится к элементам из удаленной исходной группы, к которой применяется удаленная группа вычислений, результаты меры могут по-прежнему влиять на удаленные группы вычислений. Рассмотрим следующий пример:

• Продажи торговых посредников — это мера, определенная в удаленной модели.
• Удаленная модель содержит группу вычислений, которая изменяет результат продаж торговых посредников
• Интернет-продажи — это мера, определенная в локальной модели.
• Total Sales — это мера, определенная в локальной модели, и имеет следующее определение:

[Total Sales] = [Internet Sales] + [Reseller Sales]

В этом сценарии мера "Продажи в Интернете" не влияет на группу вычислений, определенную в удаленной модели, так как они не являются частью той же модели. Однако группа вычислений может изменить результат меры продаж торгового посредника, так как они находятся в той же модели. Это означает, что результаты, возвращаемые мерой total Sales , должны быть тщательно оценены. Представьте, что мы используем группу вычислений в удаленной модели, чтобы вернуть результаты по годам. Результат, возвращаемый продажой торгового посредника, в настоящее время является текущим значением, а результат, возвращаемый интернет-продажами, по-прежнему является фактическим. Результат total Sales теперь, скорее всего, непредвиден, так как он добавляет фактический к текущему результату.

Составные модели в семантических моделях Power BI и службах Analysis Services

С помощью составных моделей с семантических моделей Power BI и служб Analysis Services можно создать составную модель с помощью подключения DirectQuery к семантической модели Power BI, Службам Azure Analysis Services (AAS) и службам SQL Server 2022 Analysis Services. С помощью составной модели можно объединить данные в этих источниках с другими данными DirectQuery и импортированными данными. Авторы отчетов, которые хотят объединить данные из корпоративной семантической модели с другими данными, которые они имеют, например электронную таблицу Excel, или хотят персонализировать или обогатить метаданные из своей корпоративной семантической модели, будут находить эту функциональность особенно полезной.

Управление составными моделями в семантических моделях Power BI

Чтобы включить создание и использование составных моделей в семантических моделях Power BI, клиент должен включить следующие параметры:

• Разрешить конечные точки XMLA и анализировать в Excel с помощью локальных семантических моделей. Если этот параметр отключен, подключение DirectQuery к семантической модели Power BI невозможно сделать.
• Пользователи могут работать с семантические модели Power BI в Excel с помощью динамического подключения. Если этот переключатель отключен, пользователи не могут выполнять динамические подключения к семантической модели Power BI, чтобы кнопка "Внести изменения в эту модель " не может быть достигнута.
• Разрешить подключение DirectQuery к семантической модели Power BI. Дополнительные сведения об этом коммутаторе см. в следующих абзацах, а также о эффекте его отключения.

Кроме того, для емкостей Premium и Premium для каждого пользователя параметр "конечная точка XMLA" должен быть включен и установлен в значение "Только для чтения" или "Только для чтения и записи".

Администраторы клиентов могут включать или отключать подключения DirectQuery к семантической модели Power BI на портале администрирования. Хотя эта функция включена по умолчанию, отключение отключает пользователей от публикации новых составных моделей в семантических моделях Power BI в службе.

Существующие отчеты, использующие составную модель в семантической модели Power BI, продолжают работать, и пользователи по-прежнему могут создавать составную модель с помощью desktop, но не могут публиковаться в службе. Вместо этого при создании подключения DirectQuery к семантической модели Power BI, выбрав "Внести изменения в эту модель ", вы увидите следующее предупреждение:

Таким образом вы по-прежнему можете изучить семантику модели в локальной среде Power BI Desktop и создать составную модель. Однако вы не можете опубликовать отчет в службе. При публикации отчета и модели вы увидите следующее сообщение об ошибке и публикацию заблокированы:

Динамические подключения к семантической модели Power BI не влияют на коммутатор, а также не являются активными или динамическими подключениями к службам Analysis Services. Они продолжают работать независимо от того, отключен ли переключатель. Кроме того, все опубликованные отчеты, использующие составную модель в семантической модели Power BI, будут продолжать работать, даже если переключатель был отключен после публикации.

Создание составной модели на семантической модели или модели

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

Чтобы узнать, какие подключения используются в модели, проверьте строку состояния в правом нижнем углу Power BI Desktop. Если вы подключены только к источнику служб Analysis Services, появится сообщение, как показано на следующем рисунке:

Если вы подключены к семантической модели Power BI, появится сообщение о том, к какой семантической модели Power BI вы подключены:

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

При нажатии кнопки отображается диалоговое окно, подтверждающее добавление локальной модели. Выберите " Добавить локальную модель ", чтобы включить создание новых столбцов или изменение метаданных для полей из семантических моделей Power BI или служб Analysis Services. На следующем рисунке показано диалоговое окно.

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

Построение цепочек

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

Например, представьте, что ваш коллега публикует семантику Power BI семантической моделью "Продажи" и "Бюджет" на основе модели служб Analysis Services и объединяет ее с листом Excel с именем "Бюджет".

При публикации нового отчета (и семантической модели) с именем Sales and Budget Europe на основе семантической модели Sales and Budget Power BI, опубликованной коллегой, делая некоторые дальнейшие изменения или расширения по мере этого, вы эффективно добавляете отчет и семантику модели в цепочку длин три длины, которая началась с модели Sales Analysis Services, и заканчивается семантической моделью продаж и бюджета Power BI. На следующем изображении показан процесс цепочки.

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

Разрешения и лицензирование

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

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

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

Необходимые разрешения можно проиллюстрировать следующим примером:

• Составная модель A (принадлежит владельцу A)

  • Источник данных A1: семантическая модель B.
    Владелец A должен иметь разрешение на сборку для семантической модели B , чтобы пользователи просматривали отчет с помощью составной модели A.

• Составная модель C (принадлежит владельцу C)

  • Источник данных C1: семантическая модель D
    Владелец C должен иметь разрешение на сборку семантической модели D , чтобы пользователи просматривали отчет с помощью составной модели C.
  • Источник данных C2: составная модель A
    Владелец C должен иметь разрешение на сборку составной модели A и разрешение на чтение для семантической модели B.

Пользователь, просматривающий отчеты с помощью составной модели A, должен иметь разрешения на чтение как составной модели A, так и семантической модели B, а пользователь, просматривающий отчеты с помощью составной модели C, семантической модели C, составной модели A и семантической модели B.

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

Предупреждение системы безопасности

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

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

Поддерживаемые сценарии

Составные модели можно создавать с помощью данных из семантических моделей Power BI или моделей служб Analysis Services для обслуживания следующих сценариев:

• Подключение к данным из различных источников: импорт (например, файлы), семантические модели Power BI, модели Analysis Services
• Создание связей между различными источниками данных
• Написание мер, использующих поля из разных источников данных
• Создание новых столбцов для таблиц из семантических моделей Power BI или моделей служб Analysis Services
• Создание визуальных элементов, использующих столбцы из разных источников данных
• Вы можете удалить таблицу из модели с помощью списка полей, чтобы сохранить модели как можно более краткие и насколько это возможно (если вы подключаетесь к перспективе, вы не можете удалить таблицы из модели).
• Вы можете указать, какие таблицы следует загружать, а не загружать все таблицы, если требуется только определенное подмножество таблиц. См. раздел "Загрузка подмножества таблиц" далее в этом документе.
• Можно указать, следует ли добавлять таблицы, которые позже добавляются в семантику модели после подключения к модели.

Работа с составной моделью на основе семантической модели

При работе с directQuery для семантических моделей Power BI и служб Analysis Services рассмотрите следующие сведения:

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

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

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

• Чтобы создать отчеты в служба Power BI на составной модели на основе другой семантической модели, необходимо задать все учетные данные.

• Для подключений к серверу SQL Server 2022 и более поздних версий служб Analysis Services в локальной среде или IAAS требуется локальный шлюз данных (стандартный режим).

• Все подключения к удаленным семантические модели Power BI выполняются с помощью единого входа. Проверка подлинности с помощью субъекта-службы в настоящее время не поддерживается.

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

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

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

  

  Дополнительные сведения об использовании столбцов дат и иерархий дат см. в статье "Применение автоматической даты или времени" в Power BI Desktop.

• Максимальная длина цепочки моделей составляет три. Расширение за пределами длины цепочки трех не поддерживается и приводит к ошибкам.

• Флаг цепочки не рекомендуется устанавливать в модели, чтобы предотвратить создание или расширение цепочки. Дополнительные сведения см. в разделе "Управление подключениями DirectQuery к опубликованной семантической модели".

• Подключение к семантической модели Power BI или модели служб Analysis Services не отображается в Power Query.

Следующие ограничения применяются при работе с DirectQuery для семантических моделей Power BI и служб Analysis Services:

• Параметры для имен баз данных и серверов в настоящее время отключены.
• Определение RLS в таблицах из удаленного источника не поддерживается.
• Использование любого из следующих источников в качестве источника DirectQuery не поддерживается:
  • Табличные модели SQL Server Analysis Services (SSAS) до версии 2022
  • Многомерные модели SSAS
  • SAP HANA
  • Хранилище SAP для бизнеса
  • Семантические модели в режиме реального времени
  • Примеры семантических моделей
  • Обновление Excel Online
  • Данные, импортированные из excel или CSV-файлов в службе
  • Метрики использования
  • Семантические модели, хранящиеся в "Моя рабочая область"
• Использование Power BI Embedded с семантических моделей, включающих подключение DirectQuery к модели служб Analysis Services, сейчас не поддерживается.
• Публикация отчета в Интернете с помощью публикации в веб-компоненте не поддерживается.
• Группы вычислений в удаленных источниках не поддерживаются с неопределенными результатами запроса.

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

• Если вы переименовываете рабочую область после настройки подключения DirectQuery, необходимо обновить источник данных в Power BI Desktop, чтобы отчет продолжал работать.
• Автоматическое обновление страницы (APR) поддерживается только для некоторых сценариев в зависимости от типа источника данных. Дополнительные сведения см. в статье "Автоматическое обновление страницы" в Power BI.
• Взять на себя семантику модели, которая использует DirectQuery для других семантических моделей , в настоящее время не поддерживается.
• Как и в любом источнике данных DirectQuery, иерархии, определенные в модели Служб Analysis Services или семантической модели Power BI, не отображаются при подключении к модели или семантической модели в режиме DirectQuery с помощью Excel.

При работе с семантических моделей Power BI и служб Analysis Services следует учитывать несколько других действий.

• Используйте столбцы с низкой кратностью в отношениях между исходными группами: при создании связи между двумя различными исходными группами столбцы, участвующие в связи (также называемые столбцами соединения), должны иметь низкую кратность, в идеале 50 000 или меньше. Это относится к нестрокным ключевым столбцам; Сведения о строковых ключевых столбцах см. в следующем разделе.
• Избегайте использования больших строковых ключевых столбцов в отношениях между исходными группами: при создании связи между исходными группами избегайте использования больших строковых столбцов в качестве столбцов связи, особенно для столбцов с большим кратностью. Если в качестве столбца связи необходимо использовать строки, вычислите ожидаемую длину строки для фильтра путем умножения кратности (C) на среднюю длину строкового столбца (A). Убедитесь, что ожидаемая длина строки ниже 250 000, поэтому ∗ C < 250 000.

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

Рекомендации по клиенту

Любая модель с подключением DirectQuery к семантической модели Power BI или службам Analysis Services должна быть опубликована в том же клиенте, что особенно важно при доступе к семантической модели Power BI или модели служб Analysis Services с использованием гостевых удостоверений B2B, как показано на следующей схеме. Ознакомьтесь с гостевыми пользователями, которые могут редактировать содержимое и управлять им, чтобы найти URL-адрес клиента для публикации.

Рассмотрим следующую схему. Нумерованные шаги на схеме описаны в следующих абзацах.

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

Для проверки подлинности Эш использует удостоверение гостевого пользователя B2B (шаг 1 на схеме).

Если отчет опубликован в служба Power BI Contoso (шаг 2), семантическая модель, опубликованная в клиенте Contoso, не может успешно пройти проверку подлинности в модели Служб Analysis Services Fabrikam (шаг 3). В результате отчет не работает.

В этом сценарии, так как используемая модель служб Analysis Services размещается в клиенте Fabrikam, отчет также должен быть опубликован в клиенте Fabrikam. После успешной публикации в клиенте Fabrikam (шаг 4) семантическая модель может успешно получить доступ к модели служб Analysis Services (шаг 5) и отчет работает правильно.

Работа с безопасностью на уровне объектов

Когда составная модель получает данные из семантической модели Power BI или служб Analysis Services через DirectQuery, а исходная модель защищена безопасностью на уровне объектов, потребители составной модели могут заметить непредвиденные результаты. В следующем разделе объясняется, как эти результаты могут возникнуть.

Безопасность на уровне объектов (OLS) позволяет авторам моделей скрывать объекты, составляющие схему модели (то есть таблицы, столбцы, метаданные и т. д.) от потребителей модели (например, построителя отчетов или составного автора модели). При настройке OLS для объекта автор модели создает роль, а затем удаляет доступ к объекту для пользователей, которым назначена эта роль. С точки зрения этих пользователей скрытый объект просто не существует.

OLS определяется и применяется к исходной модели. Его нельзя определить для составной модели, созданной на основе исходной модели.

При построении составной модели на основе семантической модели Power BI, защищенной OLS, или модели служб Analysis Services с помощью подключения DirectQuery схема модели из исходной модели копируется в составную модель. То, что копируется, зависит от того, что автор составной модели разрешено видеть в исходной модели в соответствии с правилами OLS, применяемыми к ней. Данные не копируются в составную модель, а всегда извлекаются с помощью DirectQuery из исходной модели при необходимости. Другими словами, получение данных всегда возвращается к исходной модели, где применяются правила OLS.

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

• Кто-то, глядя на составную модель, может увидеть объекты, скрытые от них в исходной модели OLS.
• И наоборот, они могут не видеть объект в составной модели, которую они могут видеть в исходной модели, так как этот объект был скрыт от составной модели автора правилами OLS, которые управляют доступом к исходной модели.

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

Учитывая этот фон, рассмотрим следующий сценарий:

1. Admin_user опубликована корпоративная семантическая модель с помощью семантической модели Power BI или модели служб Analysis Services, которая содержит таблицу Customer и таблицу "Территория". Admin_user публикует семантику модели в служба Power BI и задает правила OLS, которые имеют следующий эффект:

   • Финансовые пользователи не могут видеть таблицу Customer
   • Маркетинговые пользователи не могут видеть таблицу "Территория"

2. Finance_user публикует семантику модели семантической модели "Финансы" и отчет с именем "Финансовый отчет", который подключается через DirectQuery к корпоративной семантической модели, опубликованной на шаге 1. Отчет "Финансы" содержит визуальный элемент, использующий столбец из таблицы "Территория".

3. Marketing_user откроется отчет о финансах. Отображается визуальный элемент, использующий таблицу "Территория", но возвращает ошибку, так как при открытии отчета DirectQuery пытается получить данные из исходной модели с помощью учетных данных Marketing_user, который заблокирован для просмотра таблицы "Территория" в зависимости от правил OLS, заданных в корпоративной семантической модели.

4. Marketing_user создает новый отчет с именем "Маркетинговый отчет", который использует семантику финансов в качестве источника. В списке полей отображаются таблицы и столбцы, к которым Finance_user есть доступ. Поэтому таблица "Территория" отображается в списке полей, но таблица "Клиент" не является. Однако при попытке Marketing_user создать визуальный элемент, использующий столбец из таблицы "Территория", возвращается ошибка, так как в этот момент DirectQuery пытается получить данные из исходной модели с помощью учетных данных Marketing_user, а правила OLS снова запустите и блокируют доступ. То же самое происходит, когда Marketing_user создает новую семантику модели и сообщает, которая подключается к семантической модели Finance с подключением DirectQuery, они видят таблицу "Территория" в списке полей, так как это то, что Finance_user мог видеть, но при попытке создать визуальный элемент, использующий таблицу, они блокируются правилами OLS в корпоративной семантической модели.

5. Теперь предположим, что Admin_user обновляет правила OLS в корпоративной семантической модели, чтобы остановить просмотр таблицы "Территория".

6. Обновленные правила OLS отражаются только в семантической модели Finance при обновлении. Таким образом, когда Finance_user обновляет семантику finance, таблица "Территория" больше не отображается в списке полей, а визуальный элемент в отчете "Финансы", использующий столбец из таблицы "Территория", возвращает ошибку для Finance_user, так как теперь они не могут получить доступ к таблице "Территория".

Подведение итогов.

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

Загрузка подмножества таблиц из семантической модели Power BI или модели Analysis Services

При подключении к семантической модели Power BI или модели служб Analysis Services с помощью подключения DirectQuery можно решить, к каким таблицам необходимо подключиться. Вы также можете автоматически добавить любую таблицу, которая может быть добавлена в семантическую модель или модель после подключения к модели. При подключении к перспективе модель содержит все таблицы в семантической модели, а все таблицы, не включенные в перспективу, скрыты. Кроме того, любая таблица, которая может добавляться в перспективу, добавляется автоматически. В меню "Параметры" можно выбрать автоматическое подключение к таблицам, которые добавляются в семантику после первой настройки подключения.

Это диалоговое окно не отображается для динамических подключений.

Настройка правил дедупликации

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

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

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

После создания подключений и настройки правила дедупликации в списке полей будут отображаться как "Customer", так и "Customer (marketing)" в соответствии с правилом дедупликации, настроенным в нашем примере:

Если не указать правило дедупликации или указанные правила дедупликации не разрешают конфликт имен, то стандартные правила дедупликации по-прежнему применяются. Стандартные правила дедупликации добавляют число к имени конфликтующего элемента. Если в таблице "Customer" есть конфликт имен, то одна из таблиц "Customer" переименована в "Customer 2".

Изменения XMLA и составные модели

При изменении семантической модели с помощью XMLA необходимо обновить коллекцию ChangedProperties и PBI_RemovedChildren для измененного объекта, чтобы включить любые измененные или удаленные свойства. Если вы не выполняете это обновление, средства моделирования Power BI могут перезаписать любые изменения при следующей синхронизации схемы с соответствующим Lakehouse.

Поддерживаемые модели для изменения семантической модели с помощью XMLA приведены ниже.

• Переименование таблицы и столбца (ChangeProperty = name)
• Удаление таблицы (добавление таблицы в PBI_RemovedChildren заметки в выражении запроса)

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

Составные модели представляют несколько рекомендаций и ограничений.

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

В настоящее время добавочное обновление поддерживается только для составных моделей, подключающихся к источникам данных SQL, Oracle и Teradata.

Следующие табличные источники Live Connect нельзя использовать с составными моделями:

• SAP HANA
• Хранилище SAP для бизнеса
• Sql Server Analysis Services более ранней версии 2022
• Метрики использования (моя рабочая область)

Использование семантических моделей потоковой передачи в составных моделях не поддерживается.

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

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

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

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

• Применение связей "многие ко многим" в Power BI Desktop
• Управление режимом хранения в Power BI Desktop
• DirectQuery в Power BI
• Источники данных Power BI
• Связи модели в Power BI Desktop