Моделирование измерений в хранилище Microsoft Fabric: таблицы измерений

Область применения:✅ конечная точка аналитики SQL и хранилище в Microsoft Fabric

Примечание.

Эта статья входит в серию статей по моделированию измерений. В этой серии рассматриваются рекомендации и рекомендации по проектированию, связанные с моделированием измерений в хранилище Microsoft Fabric.

В этой статье приведены рекомендации и рекомендации по проектированию таблиц измерений в модели измерения. Он предоставляет практические рекомендации по хранилищу в Microsoft Fabric, который поддерживает множество возможностей T-SQL, таких как создание таблиц и управление данными в таблицах. Таким образом, вы полностью управляете созданием таблиц трехмерной модели и их загрузкой с данными.

Примечание.

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

Совет

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

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

Структура таблицы измерений

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

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

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

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

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

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

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

Естественные ключи

В таблице измерений примера также есть естественный ключ, который называется EmployeeID. Естественный ключ — это ключ, хранящийся в исходной системе. Он позволяет сопоставить данные измерения с исходной системой, которая обычно выполняется процессом извлечения, загрузки и преобразования (ETL) для загрузки таблицы измерений. Иногда естественный ключ называется бизнес-ключом, и его значения могут быть значимыми для бизнес-пользователей.

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

Атрибуты измерения

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

Совет

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

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

Внешние ключи;

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

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

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

Атрибуты отслеживания журнала

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

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

Атрибуты аудита

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

Размер таблицы измерения

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

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

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

Совет

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

Основные понятия проектирования измерений

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

Денормализация и нормализация

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

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

Измерения Snowflake

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

На следующей схеме показано измерение снежинки, которое состоит из трех связанных таблиц измерений: Product, Subcategoryи Category.

Рассмотрите возможность реализации измерения снежинки, когда:

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

Примечание.

Помните, что иерархия в семантической модели Power BI может основываться только на столбцах из одной семантической таблицы модели. Таким образом, измерение снежинки должно обеспечить денормализованный результат, используя представление, которое объединяет таблицы snowflake вместе.

Иерархии

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

Существует три способа хранения иерархии в измерении. Вы можете использовать:

• Столбцы из одного денормализованного измерения.
• Измерение снежинки, которое состоит из нескольких связанных таблиц.
• Отношение "родительский-дочерний" (самонаправляющийся) в измерении.

Иерархии можно сбалансировать или разбалансировать. Кроме того, важно понимать, что некоторые иерархии хватки.

Сбалансированные иерархии

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

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

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

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

Небалансированные иерархии

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

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

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

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

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

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

Совет

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

Неоднородные иерархии

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

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

На следующей схеме показана рваная иерархия географических регионов.

Управление историческим изменением

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

Ниже приведены наиболее распространенные типы SCD.

• Тип 1. Перезапись существующего элемента измерения.
• Тип 2. Вставка нового элемента измерения на основе времени на основе версий .
• Тип 3. Отслеживание ограниченного журнала с помощью атрибутов.

Возможно, измерение может поддерживать изменения типа SCD 1 и SCD типа 2.

Тип SCD 3 часто не используется, в частности, из-за того, что трудно использовать в семантической модели. Тщательно рассмотрим, подходит ли подход scD типа 2 лучше.

Совет

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

ScD type 1

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

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

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

ScD type 2

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

Это распространенный тип SCD, но он должен быть зарезервирован для атрибутов, которые должны сохранять историческую перспективу.

Например, если продавец назначается другому региону продаж, изменение SCD типа 2 включает операцию обновления и операцию вставки.

1. Операция обновления перезаписывает текущую версию, чтобы задать атрибуты отслеживания журнала. В частности, для столбца окончания срока действия задана дата обработки ETL (или подходящая метка времени в исходной системе), а текущий флаг имеет значение FALSE.
2. Операция вставки добавляет новую текущую версию, задав начальный столбец допустимости в значение столбца окончания срока действия (используется для обновления предыдущей версии) и текущий флаг TRUE.

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

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

Совет

Если таблица измерений поддерживает изменения типа SCD 2, следует включить атрибут метки, описывающий член и версию. Рассмотрим пример, когда продавец Линн Tsoflias из Adventure Works изменяет назначение из австралийского региона продаж в регион продаж Соединенного Королевства. Атрибут метки для первой версии может прочитать "Линн Tsoflias (Австралия)" и атрибут метки для новой, текущей версии может прочитать "Lynn Tsoflias (Соединенное Королевство)." Если полезно, вы также можете включить даты действия в метку.

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

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

Рассмотрим следующие атрибуты отслеживания журнала SCD типа 2.

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

Ниже приведены цели атрибутов отслеживания истории.

• Столбец RecChangeDate_FK сохраняет дату вступления в силу изменения. Он позволяет запрашивать при внесении изменений.
• RecValidToKey Столбцы RecValidFromKey хранят действующие даты допустимости строки. Рассмотрите возможность хранения самой ранней даты, найденной в измерении даты, для RecValidFromKey представления начальной версии и хранения 01/01/9999 для RecValidToKey текущих версий.
• Столбец RecReason необязателен. Он позволяет документирование причины вставки версии. Он может закодировать, какие атрибуты изменились, или это может быть код из исходной системы, которая указывает определенную бизнес-причину.
• Столбец RecIsCurrent позволяет получить только текущие версии. Он используется, когда процесс ETL ищет ключи измерения при загрузке таблиц фактов.

Примечание.

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

Тип SCD 3

SCD типа 3 изменяет ограниченный журнал с атрибутами. Этот подход может быть полезен, если необходимо записать последнее изменение или ряд последних изменений.

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

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

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

Специальные элементы измерения

Строки могут вставляться в измерение, представляющее отсутствующие, неизвестные, N/A или состояния ошибок. Например, можно использовать следующие суррогатные значения ключей.

Значение ключа	Целевые назначения
0	Отсутствует (недоступно в исходной системе)
-1	Неизвестно (сбой подстановки во время загрузки таблицы фактов)
–2	N/A (неприменимо)
-3	Ошибка

Календарь и время

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

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

Измерение даты

Измерение даты (или календаря) является наиболее распространенным измерением, используемым для анализа. Он хранит одну строку на дату и поддерживает общее требование фильтровать или группировать по определенным периодам дат, например годам, кварталам или месяцам.

Внимание

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

Естественный ключ измерения даты должен использовать тип данных даты . Суррогатный ключ должен хранить дату с помощью YYYYMMDD формата и типа данных int . Эта принятая практика должна быть единственным исключением (наряду с измерением времени), когда суррогатное значение ключа имеет значение и является удобочитаемым человеком. YYYYMMDD Хранение в виде типа данных int не только эффективно и отсортировано по числу, но и соответствует однозначному формату даты Международной организации стандартов (ISO) 8601.

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

• Year, , QuarterMonthDay
• QuarterNumberInYear— MonthNumberInYear что может потребоваться для сортировки текстовых меток.
• FiscalYear— FiscalQuarter некоторые корпоративные расписания бухгалтерского учета начинаются в середине года, поэтому начало и конец календарного года и финансовый год отличаются.
• FiscalQuarterNumberInYear— FiscalMonthNumberInYear что может потребоваться для сортировки текстовых меток.
• WeekOfYear — существует несколько способов пометить неделю года, включая стандарт ISO, имеющий либо 52 или 53 недели.
• IsHoliday— HolidayText если ваша организация работает в нескольких географических регионах, следует поддерживать несколько наборов списков праздников, которые каждая география наблюдает как отдельное измерение или натурализовано в нескольких атрибутах в измерении даты. Добавление атрибута HolidayText может помочь определить праздники для создания отчетов.
• IsWeekday - аналогичным образом, в некоторых географических регионах стандартная рабочая неделя не в понедельник до пятницы. Например, рабочая неделя в воскресенье до четверга во многих регионах Ближнего Востока, а другие регионы используют четырехдневную или шестидневную рабочую неделю.
• LastDayOfMonth
• RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffset— RelativeDayOffset что может потребоваться для поддержки фильтрации относительной даты (например, предыдущего месяца). В текущих периодах используется смещение от нуля (0); предыдущие периоды хранения смещения :1, -2, -3...; будущие периоды хранения смещения 1, 2, 3....

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

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

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

Совет

Найдите в Интернете "генератор измерений даты", чтобы найти скрипты и электронные таблицы, которые создают данные даты.

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

Измерение времени

Иногда факты должны храниться в определенный момент времени (как в время дня). В этом случае создайте измерение времени (или часов). Это может иметь зерна минут (24 x 60 = 1440 строк) или даже секунд (24 x 60 x 60 = 86 400 строк). Другие возможные зерна включают полчаса или часа.

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

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

• Hour, , HalfHourQuarterHourMinute
• Метки периода времени (утром, днем, вечером, ночью)
• Имена рабочих смен
• Пиковые или внепиковые флаги

Соответствующие измерения

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

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

На следующей схеме Sales показана таблица фактов и Inventory таблица фактов. Каждая таблица фактов относится к измерению Date и Product измерению, которые соответствуют измерениям.

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

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

Если измерение ссылается несколько раз в таблице фактов, она называется измерением, играющим ролью.

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

На следующей схеме Flight показана таблица фактов. Измерение Airport — это измерение, играющее в роли, так как оно связано дважды с таблицей фактов в качестве Departure Airport измерения и Arrival Airport измерения.

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

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

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

Хорошие кандидаты включают флаги и индикаторы, состояние заказа и демографические состояния клиентов (пол, возрастная группа и другие).

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

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

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

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

Совет

Можно создать представление в хранилище Fabric, представляющее дегенерное измерение в качестве измерения для запросов.

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

Размеры outrigger

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

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

На следующей схеме показано Geography измерение, которое является измерением внедрителя. Он не связан непосредственно с таблицей Sales фактов. Вместо этого она связана косвенно через Customer измерение и Salesperson измерение.

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

Многозначные измерения

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

Например, рассмотрим измерение продавца и то, что каждый продавец назначается одному или нескольким регионам продаж. В этом случае имеет смысл создать измерение региона продаж. Это измерение сохраняет каждый регион продаж только один раз. Отдельная таблица, известная как таблица моста, хранит строку для каждого продавца и связи между регионами продаж. Физически существует связь "один ко многим" от измерения продавца к таблице моста, а другая связь "один ко многим" из измерения региона продаж к таблице моста. Логически существует связь между продавцами и регионами продаж.

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

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

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