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

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

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

Типы составных моделей

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

Создание составных моделей в Power BI Desktop

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

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

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

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

Семантические модели, созданные с помощью таблиц Direct Lake, редактируются в Power BI Desktop. Вы можете добавить дополнительные таблицы Direct Lake. Чтобы добавить таблицы импорта, откройте семантику модели в Веб-модели Power BI. Чтобы добавить таблицы DirectQuery, используйте XMLA.

Вы можете редактировать Direct Lake и импортировать семантику модели в Desktop, но добавлять дополнительные таблицы нельзя. Таблицы можно добавлять только из веб-моделирования Power BI для Direct Lake и импортировать составные модели.

Создание составных моделей в веб-моделировании

В веб-моделировании Power BI можно создавать семантические модели с помощью импорта или таблиц Direct Lake. Нельзя добавлять таблицы DirectQuery. Чтобы создать составную модель, можно добавить дополнительные таблицы в другом режиме хранения.

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

Составные модели позволяют подключаться к различным типам источников данных при использовании 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, Direct Lake и импорта, представляет собой составную семантическую модель.

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

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

Пример составной модели рассмотрим отчет, который подключается к корпоративному хранилищу данных в 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 или импорте. Режим хранения можно просмотреть и изменить в области "Свойства ". Чтобы просмотреть режим хранения, выполните следующие действия.

1. В представлении модели выберите таблицу.
2. В области "Свойства" разверните раздел "Дополнительно ", а затем разверните список режимов хранения .

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

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

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

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

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

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

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

Составные модели имеют некоторые последствия для безопасности. Запрос, отправленный одному источнику данных, может включать значения данных, полученные из другого источника. В предыдущем примере визуальный элемент, показывающий (сумму продаж) по менеджеру по продукту, отправляет SQL-запрос в реляционную базу данных продаж. Этот 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, продолжают работать. Пользователи по-прежнему могут создавать составную модель в 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 с собственными изменениями. Эта семантическая модель является третьей в цепочке.

1. Первая цепочка — это модель служб Sales Analysis Services.
2. Вторая цепочка — это составная семантическая модель Sales and Budget Power BI.
3. Третья цепочка — это составная семантическая модель Sales и Budget Europe 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, семантической модели D, составной модели A и семантической модели B.

Если любая семантическая модель в цепочке находится в рабочей области "Премиум на пользователя", пользователю, обращающемуся к ней, требуется Premium Per User лицензия. Если любая семантическая модель в цепочке находится в рабочей области 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 Query не отображает подключение к семантической модели Power BI или модели Analysis Services.

Следующие ограничения применяются при работе с 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 (Azure Analysis Services/SQL Server Analysis Services), в настоящее время не поддерживается.
• Публикация отчета в веб с помощью функции публикации в вебе не поддерживается.
• Группы вычислений в удаленных источниках не поддерживаются с неопределенными результатами запроса.
• Вычисляемые таблицы и вычисляемые столбцы, ссылающиеся на таблицу DirectQuery из источника данных с проверкой подлинности единого входа (SSO), поддерживаются в служба Power BI с назначенным общим облачным подключением и /или детальным контролем доступа.
• Если вы переименовываете рабочую область после настройки подключения DirectQuery, необходимо обновить источник данных в Power BI Desktop, чтобы отчет продолжал работать.
• Автоматическое обновление страницы (APR) поддерживается только для некоторых сценариев в зависимости от типа источника данных. Дополнительные сведения см. в статье "Автоматическое обновление страницы" в Power BI.
• Принятие семантической модели, которая использует DirectQuery для других семантических моделей , в настоящее время не поддерживается.
• Как и в любом источнике данных DirectQuery, иерархии, определенные в модели Служб Analysis Services или семантической модели Power BI, не отображаются при подключении к модели или семантической модели в режиме DirectQuery с помощью Excel.

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

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

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

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

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

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

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

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

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

В этом сценарии, так как Fabrikam размещает модель служб Analysis Services, необходимо также опубликовать отчет в клиенте 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, которые содержат таблицу Клиент и таблицу Территория. 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 обновите коллекции ChangeProperties и PBI_RemovedChildren для измененного объекта, чтобы включить любые измененные или удаленные свойства. Если вы не обновляете эти коллекции, средства моделирования Power BI могут перезаписать изменения при следующей синхронизации схемы с источником данных.

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

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

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

Подключения в смешанном режиме — при использовании подключения смешанного режима, содержащего данные в сети (например, семантическая модель 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