Общие сведения о схеме звезд и важности Power BI

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

Внимание

Семантические модели Power BI зависят от Power Query для импорта или подключения к данным. Это означает, что для преобразования и подготовки исходных данных необходимо использовать Power Query , что может быть сложно при наличии больших объемов данных или необходимо реализовать расширенные понятия, такие как медленно изменяющиеся измерения (описанные далее в этой статье).

При появлении этих проблем рекомендуется сначала разработать процессы хранилища данных и извлечения, преобразования и загрузки (ETL) для периодической загрузки хранилища данных. Затем семантическая модель может подключиться к хранилищу данных. Дополнительные сведения см. в разделе "Моделирование измерений" в хранилище Microsoft Fabric.

Совет

Эта статья не предназначена для полного обсуждения схемы звезды. Дополнительные сведения см. непосредственно в широко опубликованных материалах, таких как Набор средств хранилища данных: Окончательное руководство по моделированию измерений (3-го выпуска, 2013) Ральфу Кимболу и другим пользователям.

Обзор схемы "Звезда"

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

• Таблицы измерений описывают бизнес-сущности — то, что вы моделировали. Сущности могут включать продукты, люди, места и понятия, включая время. Самая согласованная таблица, которую вы найдете в схеме звездочки, — это таблица измерения даты. Таблица измерений содержит ключевой столбец (или столбцы), который выступает в качестве уникального идентификатора и других столбцов. Другие столбцы поддерживают фильтрацию и группировку данных.
• Таблицы фактов хранят наблюдения или события, а также могут быть заказами на продажу, балансами акций, обменными курсами, температурами и многое другое. Таблица фактов содержит ключевые столбцы измерения, относящиеся к таблицам измерений и числовым столбцам мер. Ключевые столбцы измерения определяют размерность таблицы фактов, а значения ключа измерения определяют степень детализации таблицы фактов. Например, рассмотрим таблицу фактов, предназначенную для хранения целевых объектов продажи с двумя ключевыми столбцами Date измерения и ProductKey. Легко понять, что таблица имеет два измерения. Однако степень детализации не может быть определена без учета значений ключа измерения. В этом примере следует учитывать, что значения, хранящиеся в Date столбце, являются первым днем каждого месяца. В этом случае степень детализации находится на уровне месячного продукта.

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

Нормализация и денормализация

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

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

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

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

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

Релевантность схемы "Звезда" для семантических моделей Power BI

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

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

• Таблицы измерений позволяют фильтровать и группировать.
• Таблицы фактов позволяют сводные данные.

Нет свойства таблицы, которое моделиаторы задают тип таблицы как измерение или факт. На самом деле это определяется связями модели. Связь модели устанавливает путь распространения фильтра между двумя таблицами, и это свойство кратности связи, определяющей тип таблицы. Общая кратность отношений — один ко многим или обратное. "Одна" сторона всегда является таблицей измерений, а сторона "многие" всегда является таблицей фактов.

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

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

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

• Меры
• Суррогатные ключи
• Измерения Snowflake
• Измерения воспроизведения ролей
• Медленно изменяющиеся измерения
• Измерения нежелательной почты
• Вырожденные измерения
• Таблицы фактов без фактов

Показатели

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

• Явные меры создаются явно, и они основаны на формуле, написанной в выражениях анализа данных (DAX), которая достигает суммирования. Выражения мер часто используют функции агрегирования DAX, такие как SUM, , MAXMINи AVERAGEдругие, чтобы получить скалярный результат значения во время запроса (значения никогда не хранятся в модели). Выражение меры может варьироваться от простых агрегатов столбцов до более сложных формул, которые переопределяют контекст фильтра и /или распространение связей. Дополнительные сведения см. в статье "Основы DAX" в Power BI Desktop.
• Неявные меры — это столбцы, которые можно суммировать с помощью визуального элемента отчета или Q&A. Они предлагают удобство для вас в качестве разработчика модели, так как во многих случаях вам не нужно создавать (явные) меры. Например, столбец продаж Sales Amount торгового посредника Adventure Works можно суммировать различными способами (суммы, подсчета, среднего, медианы, мина, максимума и других), без необходимости создания меры для каждого возможного типа агрегирования.

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

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

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

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

• Если вы хотите управлять тем, как авторы отчета суммируют столбцы определенными способами. Например, столбец продаж Unit Price торгового посредника (который представляет ставку на единицу) можно суммировать, но только с помощью определенных функций агрегирования. Она никогда не должна быть суммирована, но она подходит для суммирования с помощью других функций агрегирования, таких как min, max или average. В этом экземпляре модельер может скрыть Unit Price столбец и создать меры для всех соответствующих функций агрегирования.

  Этот подход к проектированию хорошо подходит для отчетов, созданных в служба Power BI и для Q&A. Однако динамические подключения Power BI Desktop позволяют авторам отчетов отображать скрытые поля на панели данных, что может привести к обходу этого подхода к проектированию.

Суррогатные ключи

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

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

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

Измерения Snowflake

Измерение snowflake — это набор нормализованных таблиц для одной бизнес-сущности. Например, Adventure Works классифицирует продукты по категориям и подкатегории. Продукты назначаются подкатегориям, и подкатегории, в свою очередь, назначаются категориям. В реляционном хранилище данных Adventure Works измерение продукта нормализуется и хранится в трех связанных таблицах: DimProductCategory, DimProductSubcategoryи DimProduct.

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

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

При выборе имитации макета измерения snowflake:

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

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

Медленно изменяющиеся измерения

Медленно изменяющееся измерение (или SCD) является одним из них, который соответствующим образом управляет изменением элементов измерения с течением времени. Она применяется, когда значения бизнес-сущностей изменяются медленно с течением времени незапланированным образом. Хорошим примером SCD является измерение клиента, так как его столбцы контактных данных, такие как адрес электронной почты и номер телефона, редко изменяются. В отличие от этого, некоторые измерения считаются быстро изменяющимися при частом изменении атрибута измерения, например рыночной цены акций. Распространенный подход к проектированию в этих экземплярах заключается в хранении быстро меняющихся значений атрибутов в меры таблицы фактов.

Теория схемы "Звезда" относится к двум общим типам SCD: Тип 1 и Тип 2. Таблица измерений может быть типом 1 или типом 2 или поддерживать оба типа одновременно для разных столбцов.

Тип 1 SCD

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

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

Тип 2 SCD

Медленно изменяющееся измерение типа 2 поддерживает управление версиями для элементов измерения. Если исходная система не хранит версии, обычно это процесс загрузки хранилища данных, который обнаруживает изменения и соответствующим образом управляет изменением таблицы измерений. В этом случае таблица измерений должна использовать суррогатный ключ для предоставления уникальной ссылки на версию элемента измерения. Он также содержит столбцы, определяющие допустимость диапазона дат версии (например, StartDate и EndDate) и, возможно, столбец флага (например, IsCurrent), чтобы легко фильтровать по текущим элементам измерения.

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

Важно понимать, что если исходные данные не хранят версии, необходимо использовать промежуточную систему (например, хранилище данных) для обнаружения и хранения изменений. Процесс загрузки таблицы должен сохранять существующие данные и обнаруживать изменения. При обнаружении изменения процесс загрузки таблицы должен истекть до текущей версии. Он записывает эти изменения, обновляя EndDate значение и вставляя новую версию со StartDate значением, начиная с предыдущего EndDate значения. Кроме того, связанные факты должны использовать поиск на основе времени для получения значения ключа измерения, относящееся к дате фактов. Семантическая модель Power BI использует Power Query и поэтому не может получить этот результат. Однако он может загружать данные из предварительно загруженной таблицы измерений SCD Типа 2.

Совет

Сведения о реализации таблицы измерений SCD типа 2 в хранилище Fabric см. в статье "Управление историческими изменениями".

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

Чтобы достичь этого требования, таблица измерения семантической модели Power BI должна содержать столбец для фильтрации продавца и другой столбец для фильтрации определенной версии продавца. Важно, чтобы столбец версии предоставлял неоднозначное описание, например David Campbell (12/15/2008-06/26/2019) или David Campbell (06/27/2019-Current). Кроме того, важно обучить авторов отчетов и потребителей основам SCD Type 2 и как достичь соответствующих конструкций отчетов путем применения правильных фильтров.

Рекомендуется включить иерархию, которая позволяет визуальным элементам детализации до уровня версии.

Ролевые измерения

Измерение воспроизведения ролей — это измерение , которое может фильтровать связанные факты по-разному. Например, в Adventure Works таблица измерений даты имеет три отношения с фактами продаж торгового посредника. Ту же таблицу измерений можно использовать для фильтрации фактов по дате заказа, дате доставки или дате доставки.

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

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

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

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

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

Чтобы преодолеть эти ограничения, распространенный метод моделирования Power BI — создать таблицу измерений для каждого экземпляра, играющего роль. Вы можете создать каждую таблицу измерений в виде запроса ссылки с помощью Power Query или вычисляемой таблицы с помощью DAX. Модель может содержать таблицу Date , Ship Date таблицу и Delivery Date таблицу с одной и активной связью с соответствующими столбцами таблицы продаж торгового посредника.

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

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

• Убедитесь, что имена столбцов самоописываются. Хотя столбец можно использовать Year во всех таблицах дат (имена столбцов уникальны в своей таблице), они не самоописываются по умолчанию. Рекомендуется переименовать столбцы в каждой таблице ролей измерения, чтобы Ship Date таблица содержит столбец года с именем Ship Yearи т. д.
• При необходимости убедитесь, что описания таблиц предоставляют отзывы авторам отчетов (с помощью подсказок области данных ) о настройке распространения фильтров. Эта ясность важна, если модель содержит универсальную именованную таблицу, например Date, которая используется для фильтрации множества таблиц фактов. В случае, если эта таблица имеет, например, активную связь с столбцом даты заказа на продажу торгового посредника, рассмотрите возможность предоставления описания таблицы, например Filters reseller sales by order date.

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

Измерения нежелательной почты

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

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

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

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

Вырожденные аналитики

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

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

Тем не менее, если в таблице продаж торгового посредника Adventure Works есть число заказов и столбцы номеров строк заказа, и они необходимы для фильтрации, создание вырожденной таблицы измерений будет хорошим дизайном. Дополнительные сведения см . в руководстве по связям "один к одному" (вырожденные измерения).

Таблицы фактов без фактов

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

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

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

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

Этот подход проектирования "многие ко многим" хорошо документирован, и его можно достичь без бриджинга таблицы. Однако подход к таблице бриджинга считается лучшей практикой при связывании двух измерений. Дополнительные сведения см . в руководстве по связям "многие ко многим" (связь с двумя таблицами типов измерений).

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

Дополнительные сведения о схеме звезд или семантической модели Power BI см. в следующих статьях:

• Статья Википедии по моделированию измерений
• Связи модели в Power BI Desktop
• Руководство по отношениям "один к одному"
• Руководство по связям "многие ко многим"
• Руководство по двунаправленным отношениям
• Руководство по активной и неактивной связи
• Моделирование измерений в хранилище Microsoft Fabric
• Вопросы? Попробуйте запросить сообщество Fabric
• Есть предложения? Участие в разработке идей по улучшению Структуры