что такое модель данных в power bi

Руководство по Power Bi: начало работы

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

Введение

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

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

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

Компоненты Power BI

Power BI состоит из классического приложения для Microsoft Windows — Power BI Desktop, веб-службы SaaS (программное обеспечение как услуга), называемой службой Power BI, и мобильных приложений Power BI, доступных на смартфонах и планшетах Windows, а также на устройствах Apple iOS и Google Android.

Эти три элемента (Desktop, служба и мобильные приложения) позволяют людям создавать, использовать аналитические бизнес-сведения и обмениваться ими наиболее эффективно с точки зрения личных или служебных задач.

Взаимосвязь Power BI с вашей ролью

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

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

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

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

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

Последовательность работы в Power BI

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

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

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

Использование Power BI

Теперь, когда вы знаете основы Microsoft Power BI, давайте перейдем к практическим знаниям и пошаговому руководству.

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

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

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

Следующие части изучайте на нашем сайте Microsoft learn:

Источник

Рекомендации по разработке составной модели в Power BI Desktop

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

Общие сведения о составных моделях в этой статье не приводятся. Если вы не знакомы с составными моделями, рекомендуем сначала ознакомиться со статьей Использование составных моделей в Power BI Desktop.

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

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

По возможности лучше всего разработать модель в режиме импорта. Этот режим обеспечивает наибольшую гибкость проектирования и наилучшую производительность.

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

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

Составные модели не могут объединять подключения к внешним аналитическим базам данных. Это касается динамических подключений к внешним моделям, наборам данных Power BI, SAP Business Warehouse и SAP HANA (считая SAP HANA многомерным источником).

Оптимизация схемы модели

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

Режим хранения таблиц

В составной модели вы можете настроить режим хранения для каждой таблицы (кроме вычисляемых таблиц):

Существует несколько возможных сценариев, когда Power BI запрашивает составную модель:

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

Агрегации

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

Мы рекомендуем, чтобы таблица агрегирования следовала основному правилу: количество ее строк должно быть как минимум в 10 раз меньше, чем в базовой таблице. Например, если в базовой таблице хранится 1 миллиард строк, то в таблице агрегирования количество строк не должно превышать 100 миллионов. Это правило обеспечивает адекватный рост производительности по сравнению со стоимостью создания и обслуживания таблицы агрегирования.

Дальнейшие действия

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

Источник

Наборы данных в службе Power BI

В этой статье содержится техническое описание наборов данных Power BI.

Типы наборов данных

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

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

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

Модели с внешним размещением

Существует два типа моделей с внешним размещением: SQL Server Analysis Services и Azure Analysis Services.

Подключение к модели SQL Server Analysis Services предусматривает установку локального шлюза данных, будь то локальная среда или инфраструктура как услуга (IaaS), размещенная на виртуальной машине. Службам Azure Analysis Services наличие шлюза не требуется.

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

Модели, разработанные для Power BI Desktop

Power BI Desktop — клиентское приложение, предназначенное для разработки Power BI, может использоваться для разработки моделей. Модель фактически является по сути табличной моделью Analysis Services. Разработать модели можно путем импорта данных из потоков данных, которые затем можно интегрировать с внешними источниками данных. Несмотря на то что подробные сведения о моделировании не приведены в этой статье, важно знать, что с помощью Power BI Desktop можно разработать три различных типа (или режима) моделей. Эти режимы определяют, импортируются ли данные в модель или же они остаются в источнике данных. Вот эти три режима: режим импорта, режим DirectQuery и составной режим. Дополнительные сведения о каждом режиме см. в статье Режимы наборов данных в службе Power BI.

Модели с внешним размещением и модели Power BI Desktop могут применять безопасность на уровне строк (RLS) для ограничения данных, получаемых определенным пользователем. Например, пользователи, назначенные в группу безопасности Менеджеры, могут просматривать данные отчета только для тех регионов продаж, которые им назначены. Роли RLS могут быть динамическими или статическими. Динамические роли можно отфильтровать по пользователям отчета, тогда как статические роли применяют одинаковые фильтры для всех пользователей, которым назначена роль. Дополнительные сведения см. в статье Безопасность на уровне строк (RLS) в Power BI.

Модели книги Excel

Создание наборов данных на основе книг Excel или CSV-файлов приведет к автоматическому созданию модели. Таблицы Excel и данные CSV импортируются для создания таблиц модели, а модель данных книги Excel транспонируется для создания модели Power BI. Во всех случаях данные файла будут импортированы в модель.

Итоги

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

Ниже приведены важные факты о наборах данных Power BI, которые представляют модели:

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

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

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

Источник

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

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

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

Для доступа к представлению моделирования выберите значок модели на панели Power BI Desktop слева, как показано на следующем рисунке.

Создание отдельных диаграмм

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

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

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

Настройка общих свойств

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

Например, можно изменить режим хранения для нескольких таблиц в представлении диаграммы. Для этого удерживайте нажатой клавишу CTRL, выберите таблицы, а затем измените параметр режима хранения в области Свойства.

Дальнейшие шаги

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В представлении связей в Power BI Desktop теперь также отображается дополнительная таблица ProductManagers.

После создания этой связи она отображается в представлении связей в Power BI Desktop, как и ожидалось.

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

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

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

Пример на следующем рисунке основан на новых данных и связях, которые мы создали. Визуальный элемент в нижнем левом углу отражает сравнение общего объема продаж (Sales Amount) и целевого показателя (Target), а также вычисленное значение дисперсии. Данные Sales Amount и Target поступают из двух разных баз данных SQL Server.

Установка режима хранения

У каждой таблицы в составной модели есть режим хранения, указывающий, на чем основана таблица (на DirectQuery или импорте). Режим хранения можно просмотреть и изменить в области Свойства. Чтобы увидеть режим хранения, в списке Поля щелкните таблицу правой кнопкой мыши, а затем выберите пункт Свойства. На следующем рисунке показан режим хранения для таблицы SalesTargets.

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

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

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

В Power BI Desktop и в службе Power BI можно использовать режим смешанного хранения.

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

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

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

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

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

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

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

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

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

Кроме того, если автор добавляет Таблицу 1 из Модели А в составную модель (для справки назовем ее Моделью В), то пользователь, просматривающий отчет, созданный на основе Модели В, может выполнить запрос к любой таблице в Модели А, которая не защищена с помощью RLS.

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

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

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

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

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

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

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

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

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

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

В этом выпуске составные модели представляют несколько ограничений:

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

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

При подключении к этим многомерным источникам в режиме DirectQuery невозможно одновременно подключиться к другому источнику DirectQuery или сочетать его с импортированными данными.

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

Дальнейшие действия

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

Источник