Недавно мы писали об отношениях и кардинальности отношений. Сейчас самое время объяснить два типа таблиц, с которыми мы имеем дело каждый день в модели данных отчетности: таблицы фактов (Fact) и измерений (Dimension). В этой статье мы объясним, что такое таблица измерений и ее примеры, и как ее можно создать. Хотя во всех примерах этой статьи используются Power BI и Power Query, основы моделирования действительны независимо от используемого вами инструмента. Если вы слышали о Dimension и не знаете, что это такое, или не слышали об этом и хотите создать модель данных для отчетов, вам нужно прочитать эту статью.

Два типа таблиц

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

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

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

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

Тип поля: описательный

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

Следующая таблица представляет собой таблицу, полную информации о клиентах, и все они представляют собой данные типа текстовых данных:

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

В большинстве случаев вы используете значения из этой таблицы на оси или в условных обозначениях диаграммы визуализации, но не в качестве значений. (Вы можете использовать их в качестве значений в визуале таблицы, но это исключение, визуал таблицы, покажет вам все). На приведенном выше снимке экрана значением является SalesAmount (из другой таблицы), и оно всегда имеет срезы вдоль и поперек по полю из таблицы Customer: Gender, EnglishEducation, Lastname. Это подводит нас к первой части определения таблицы измерений.

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

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

Поле даты (BirthDate) и числовое поле (YearlyIncome) также будут использоваться для нарезки вдоль и поперек, как показано на этом скриншоте:

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

Тип данных описательных полей может быть текстом, датой и временем, числом или

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

Другой тип поля: значения

Описательное поле - не единственный тип поля, с которым мы работаем в модели данных. Существует также другой тип поля, которое называется Факт. Эти поля не используются для нарезки вдоль и поперек. Эти поля используются в качестве ЗНАЧЕНИЙ в визуализации. Во всех приведенных выше визуализациях было поле, являющееся частью значения визуала: SalesAmount.

SalesAmount не используется для нарезки данных вдоль и поперек. Он используется в качестве значения. Фактически, SalesAmount разделен на части с помощью описательных полей Gender, Education,и Lastname. SalesAmount не является описательным полем, это поле, которое используется в качестве значения и иногда может быть агрегировано (например, то, что вы видите в SalesAmount по Gender или SalesAmount по EnglishEducation). SalesAmount - это поле FACT.

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

Золотое правило: факты и описательные поля не должны быть в одной таблице!

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

Давайте предположим, что у нас есть таблица с обоими типами полей; описательные поля, а также поля фактов, как показано ниже:

Все семь первых полей являются описательными, а последние два (SalesAmount и Order Quantity) являются полями фактов. Использование его в модели, подобной приведенной выше, прекрасно работает, и вы можете нарезать данные вдоль и поперек полей фактов с помощью описательных полей. Тем не менее, что, если вы принесете другой набор описательных полей, которые не являются частью этой таблицы? Например, что если вы хотите нарезать данные вдоль и поперек полей фактов по некоторым полям из таблицы Product, таким как ProductName, Color и т. д.? Затем вы в конечном итоге привносите все эти данные в эту таблицу и получаете очень большую таблицу, в которой указаны покупатели, продукты и значения продаж! Что если позже вы захотите указать даты транзакций, стимулирование продаж, информацию о магазине? Каждый из таких типов данных принесет с собой множество полей.

Скажите нет одной таблице, включающей все!

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

• Обслуживание такой большой таблицы всегда будет проблемой. Каждый раз, когда вы добавляете новый набор полей, вы должны объединить их в эту таблицу.
• Уровень данных, хранящихся в этой таблице, зависит от полей в ней. Если вы принесете новые поля, вам нужно хранить больше деталей! Это тоже проблема технического обслуживания.
• Объединение не всегда возможно! Что, если вы также хотите внести бюджет в ту же таблицу? В большинстве случаев это невозможно, поскольку у вас могут отсутствовать бюджетные данные на уровне клиента, вы можете иметь их только на уровне месяца и продукта. Тогда вы получите несколько очень больших таблиц.

Проблема обслуживания

Каждый раз, когда вы добавляете новые поля, ваша таблица должна быть объединена с новой таблицей, чтобы все было в одном месте!

Уровень детализации зависит от полей в таблице! Если вы добавите больше полей, вам нужно хранить больше деталей.

Объединение не всегда возможно

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

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

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

Таблица измерений

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

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

Эта таблица должна быть связана с другими таблицами, включая поля фактов, чтобы разделить и нарезать их данные. Поэтому в этой таблице должно быть поле, которое является уникальным идентификатором для каждой строки. Это поле в практиках проектирования баз данных называется первичным ключом (Primary Key). Первичный ключ - это отдельное поле или комбинация полей в таблице измерений, которые могут однозначно идентифицировать каждую строку. Например, таблица Customer может быть идентифицирована с помощью столбца CustomerKey, как показано ниже:

Это поле, которое будет использоваться для отношений «один ко многим» между таблицей измерений и таблицами фактов:

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

Итак, нам нужно немного изменить наше определение сейчас;

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

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

Когда первичный ключ не является первичным ключом!

Первичный ключ - это столбец (предположим, что в этом примере это только один столбец), то есть идентификатор строки. Однако что, если это не так? Помните ли вы в своих сценариях использования сценарий, что что-то должно быть первичным ключом, но может им не быть? Вот пример: в модели отчетности для банковской информации у нас есть таблица кредитных карт. Каждая кредитная карта имеет уникальный номер, поэтому может использоваться в качестве первичного ключа:

Однако, если вы посмотрите более подробно, кредитная карта будет обновляться каждые несколько лет, с новой датой истечения срока действия, но с тем же номером!

Это пример поля, которое должно быть каким-то образом первичным ключом (или, может быть, это уже первичный ключ в исходной операционной системе), но не в нашей модели. мы называем эти поля; Альтернативный ключ, бизнес-ключ или первичный ключ в исходной системе. И затем нам нужно создать новое поле в таблице измерений, которое может быть реальным первичным ключом. По этой причине первичный ключ таблицы измерений называется суррогатным ключом (Surrogate Key), и в большинстве случаев его можно сгенерировать как значение индекса для автоматического нумерации:

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

Сделайте таблицы измерений широкими

Другое золотое правило при разработке таблиц измерений - делать их широкими. Добавьте поля, которые связаны с этим, больше полей в таблице измерений означает большую мощность для нарезки данных вдоль и поперек. Если у вас есть только три поля «Имя», «Фамилия» и «Пол» клиента, то это означает, что вы можете нарезать данные только по этим трем полям. Однако, если у вас есть таблица клиентов со всеми нижеприведенными столбцами, то у вас будет гораздо больше возможностей в нарезке вдоль и поперек:

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

Таблицы измерений поверхностны

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

Примеры таблиц измерений

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

Клиент: CustomerKey, First name, Last name, Full name, Age, Gender, Job title и т. д.

Продукт: ProductKey, Product Number (Alternate key), Product Name, Color, Size и т. д.

Магазин: StoreKey, Name, Address и т.д.

Резюме

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

No Comments