Проектируйте схему звезды для семантических моделей
Вы выбрали, как данные поступают в вашу семантическую модель. Сейчас создайте звездную схему, которая упорядочивает данные для четких и эффективных запросов. Звёздная схема соединяет таблицы фактов с таблицами измерений через связи, создавая пути фильтрации, от которых зависят отчёты и использование ИИ. Если вы знакомы со звездной схемой в Power BI Desktop, данный урок сфокусирован на решениях по проектированию связей, которые имеют значение по мере увеличения сложности и масштаба моделей.
Схема "Звезда" в семантической модели
В схеме звездочки таблицы фактов хранят измеримые бизнес-события (например, транзакции продаж, строки заказов и веб-визиты), а таблицы измерений предоставляют описательный контекст (например, сведения о продукте, сведения о клиенте и атрибуты даты). Таблицы измерений фильтруют таблицы фактов с помощью связей, что позволяет пользователям срезать метрики по любому описательному атрибуту.
В семантической модели Fabric этот шаблон обеспечивает четкое распространение фильтров как для отчетов, так и для анализа с использованием ИИ. Когда Copilot или агент данных создает запрос естественного языка, хорошо организованная звездная схема дает ИИ четкие пути к правильным данным. Неоднозначные или циклические связи путают как потребителей отчетов, так и средства искусственного интеллекта.
Как режим хранения влияет на связи
Связи в семантической модели ведут себя по-разному в зависимости от режима хранения. Понимание этих различий важно для разработки схемы звезды, которая демонстрирует высокую производительность в различных сценариях.
Связи Direct Lake
В режиме Direct Lake подсистема считывает связи непосредственно из метаданных таблицы Delta. Отношения функционируют наилучшим образом, когда:
- Ключевые столбцы измерения имеют низкую кардинальность относительно строк таблицы фактов.
- Целостность ссылок сохраняется в исходных данных. Когда поддерживается целостность ссылок, движок использует соединения INNER вместо LEFT OUTER соединений, что повышает производительность запросов.
- Столбцы, используемые в отношениях, индексируются в базовых таблицах Delta.
Замечание
Если запрос включает связь, которая приводит к превышению пределов памяти модели или использованию неподдерживаемых операций, Direct Lake возвращается в DirectQuery, а поведение связи изменяется в соответствии с семантикой DirectQuery.
Связи между источниками
Семантические модели в Fabric могут подключать таблицы из разных хранилищ данных. Таблица фактов из lakehouse может иметь связь с таблицей измерений из хранилища или с таблицей, доступной через конечную точку аналитики SQL. Эти межисточниковые подключения используют возможности составной модели.
Когда таблицы приходят из разных источников, режим хранения для каждой таблицы определяет, как связь работает во время запроса. Движок обрабатывает каждую часть независимо и объединяет результаты.
Типы отношений
Отношения "один ко многим"
Один ко многим является наиболее распространенным типом связи в звёздной схеме. Одно уникальное значение в таблице измерений связано с множеством строк в таблице фактов. Например, одна строка продукта в измерении Product соответствует тысячам строк заказа в таблице фактов продаж.
Настройте отношения "один ко многим" с направлением фильтра, направленным из измерения ("одна" сторона) в таблицу фактов ("многих" сторон). Это стандартный шаблон фильтра схемы звездочек.
Отношения «многие ко многим»
Связи "многие ко многим" требуются, если ни одна таблица не имеет уникальных значений для столбца связи. Используйте сводную таблицу для разрешения этих связей. Связующая таблица находится между двумя таблицами и содержит уникальные комбинации ключей из обоих связанных наборов данных.
Например, если у клиента может быть несколько учетных записей, а учетная запись может принадлежать нескольким клиентам, связующая таблица Клиент-Учетная запись определяет связь. Таблица моста имеет отношения "один ко многим" к таблицам "Клиент" и "Учетная запись".
Направление фильтрации
В большинстве реализаций схем звезд используйте однонаправленную фильтрацию от измерения к факту. Это обеспечивает прогнозируемое распространение фильтров и избегает неоднозначности в результатах запроса.
Двунаправленная фильтрация иногда необходима для связей "многие ко многим" или при фильтрации таблиц измерений по значениям в таблице фактов. Используйте двунаправленные фильтры осмотрительно, потому что они могут ухудшить производительность запросов и вызвать нежелательное поведение фильтров в отчетах.
Целостность ссылок
Параметр "Предполагаем целостность ссылок" указывает движку использовать внутренние соединения вместо левых внешних соединений при запросах по отношению. В режимах Direct Lake и DirectQuery этот параметр может значительно повысить производительность, так как уменьшает количество строк, выполняемых обработчиком.
Включите этот параметр, если вы уверены, что каждое значение внешнего ключа в таблице фактов имеет соответствующее значение в таблице измерений. Если нарушается целостность ссылок, строки с несовпадными ключами автоматически исчезают из результатов запроса.
Неактивные связи и USERELATIONSHIP
Одновременно может существовать только одна активная связь между двумя таблицами. Если требуется несколько путей связи (например, дата заказа и дата отправки, относящиеся к одному измерению даты), сделайте одну связь активной и другой неактивной.
Используйте функцию USERELATIONSHIP в DAX для активации неактивной связи в вычислении:
Shipped Amount =
CALCULATE(
SUM(Sales[Amount]),
USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)
Этот шаблон обеспечивает очистку модели при поддержке нескольких аналитических перспектив на одних и том же данных.
Обработка схемы типа "снежинка" в семантических моделях
Исходные данные часто поступают в нормализованной схеме снежинки, в которой таблицы измерений распределены по нескольким связанным таблицам. Например, измерение «Продукт» может быть разделено на таблицы «Продукт», «Подкатегория» и «Категория», каждая из которых связана через внешние ключи.
В семантической модели у вас есть два варианта: расплющить снежинку в схему звезды или сохранить нормализованную структуру.
Преобразовать в звездчатую схему
Выравнивание означает объединение нормализованных таблиц измерений в одну денормализованную таблицу измерений. Таблица продуктов будет непосредственно включать столбцы подкатегории и категории, устраняя необходимость в дополнительных таблицах и связях.
Уплощение при условии:
- Объединенная таблица измерений все еще невелика по сравнению с таблицей фактов (что почти всегда имеет место для измерений).
- Требуется более простой путь фильтрации от измерения к факту. Каждый фильтр проходит через единственную связь вместо цепочки.
- Потребление ИИ является приоритетом. Меньшее количество таблиц и более простые связи обеспечивают инструменту Copilot и агентам данных более четкие пути к точным данным.
Плоские таблицы измерений во время подготовки данных в лейкхаусах или потоках данных до достижения семантической модели. Используйте слияния Power Query, соединения SQL или трансформации в записной книжке для объединения нормализованных таблиц в одно измерение.
Сохранение структуры снежинки
В некоторых случаях сохранение нормализованной структуры имеет смысл:
- Иерархия измерений имеет несколько уровней, а выравнивание создаст десятки избыточных столбцов.
- Несколько таблиц фактов используют субдименсионные таблицы (например, общую таблицу категорий, используемую как фактами продаж, так и запасов), и денормализация приведет к созданию несогласованных версий.
- Безопасность на уровне строк должна применяться на определенном уровне иерархии.
При сохранении структуры снежинки необходимо тщательно настроить связи. Каждая связь в цепочке должна использовать однонаправленную фильтрацию от самой внешней таблицы к таблице фактов, чтобы фильтры распространялись правильно. Фильтр по категории должен проходить через подкатегорию, а затем через Продукт и в таблицу фактов.
Замечание
В большинстве сценариев семантической модели выравнивание размеров в схеме звезд лучше всего подходит. Меньше таблиц означает меньше связей, более простой DAX, более быстрые запросы и более эффективное использование ИИ. Сохраните структуру снежинки только в том случае, если есть веская причина сохранить ее.
Когда использовать составные модели для сценариев с несколькими источниками
Используйте составные модели, если схема звезды охватывает несколько хранилищ данных Fabric или включает внешние источники. Ниже приведены распространенные сценарии.
- Таблицы фактов в озере с таблицами измерений, которые хранятся в складе.
- Потоковая передача данных из хранилища событий в режиме реального времени в сочетании с историческими данными в лейкхаусе.
- Справочные данные из внешнего источника (импорт) в сочетании с таблицами фактов на основе Fabric (Direct Lake).
В этих сценариях настройте режим хранения для каждой таблицы независимо и убедитесь, что связи между различными источниками данных выполняются приемлемо при ожидаемыми объемами данных.