Мусорное измерение: что это такое и почему это не мусор

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

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

Оглавление

• Что такое нежелательные измерения?
• Определение размеров мусора с помощью аналогии кухонного ящика для мусора
• Уменьшение размера таблицы фактов
• Рассмотрение проблемы участника форума
• Моделирование данных для нежелательного измерения
• Определение типа клиента для нежелательного измерения
• Удаление ненужных столбцов
• Заключение

Что такое нежелательные измерения?

The Data Warehouse Toolkit Кимбалла и Росса , одна из библий многомерного моделирования, определяет его как группировку флагов и индикаторов типично низкой кардинальности . Низкая кардинальность означает небольшое количество уникальных наблюдений в заданном поле.

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

Определение размеров мусора с помощью аналогии кухонного ящика для мусора

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

Аналогия кухонного ящика для мусора для измерения мусора — хорошая. У каждого есть ящик, набитый резинками, скобами, батарейками, свечами на день рождения и так далее. Для любой из этих вещей не обязательно иметь собственный ящик, но вам нужно иметь место для их размещения.

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

Уменьшение размера таблицы фактов

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

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

Рассмотрение проблемы участника форума

Давайте взглянем на конкретное приложение, которое было размещено на форуме. Участник хотел создать два разных поля: одно для Stalled и одно для Active . Если клиент совершил транзакцию за последние 45 дней, она помечается как активная; в противном случае он помечается как остановленный.

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

Итак, это два флага, которые мы хотим развивать. Давайте перейдем к LuckyTemplates и выясним, как это сделать.

Моделирование данных для нежелательного измерения

Давайте посмотрим на модель данных. Это очень простая модель данных. У нас есть расширенная таблица Dates и таблица Transactions .

В нашей таблице транзакций всего три поля: номер счета , дата счета и объем продаж .

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

Мы должны делать это либо в power query, либо в хранилище данных/SQL, если у нас есть такая возможность. Но пока давайте предположим, что мы этого не делаем и просто делаем это в power query .

Определение типа клиента для нежелательного измерения

Первое, что мы сделаем, это выясним тип клиента, будь то транзакция с одним или несколькими заказами. Мы будем использовать Group By , Count и Count Rows .

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

Давайте посмотрим на результат и расширим его.

Мы можем добавить настраиваемый столбец и назвать его Тип клиента , а затем создать оператор IF. Утверждение: если Count равно 1, то это один заказ; в противном случае это многопорядковый.

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

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

Мы добавим пользовательский столбец и назовем его Today . Затем добавьте DateTime.LocalNow , чтобы дать нам текущую дату и время, затем Date.From , чтобы дать нам только часть даты.

Давайте просто изменим это на тип данных даты, а затем переместим столбец на передний план.

Существует простой способ создать вычитание между двумя столбцами дат. Просто выделите эти две даты, нажмите «Даты» на ленте, а затем нажмите «Вычесть дни» .

Это даст вам разницу между этими двумя датами с точки зрения количества дней. Назовем этот новый столбец «Дни до сегодняшнего дня».

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

Давайте сделаем еще Group By , затем Advanced , затем Account Number .

Опять же, мы будем использовать All Data для имени нового столбца и All Rows для операции.

На этот раз мы добавим « Минимум дней между с минимумом » в качестве операции и «Дней до сегодняшнего дня» в качестве столбца. Это даст нам самый последний заказ.

Затем мы расширяем All Data и удаляем Account Number .

Как только мы расширим это, у нас будет минимальное количество дней между номерами счетов.

Наконец, мы добавим еще один настраиваемый столбец и назовем его Client Timing . Мы добавим параметр «что, если», где, если наш Min Days Between меньше или равен 45, то он является Active или Stalled .

Удаление ненужных столбцов

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

Мы удалим столбцы Count , Today , Days Before to Today и Min Days Between . Теперь у нас есть только исходная таблица фактов, а также столбцы «Тип клиента» и «Время клиента» .

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

Мы назовем дубликат таблицы Account Flags .

Вернемся к таблице «Транзакции» и уберем поля «Тип клиента» и «Время клиента» .

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

Для таблицы «Флаги учетной записи» нам не нужны поля «Тип клиента» и «Время клиента» , поэтому мы их убираем. Мы просто выделяем все эти поля, удаляем строки и удаляем дубликаты.

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

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

Построение отношений модели данных в LuckyTemplates
Моделирование данных в LuckyTemplates: советы и рекомендации

Заключение

Давайте поместим измерения Client Timing и Client Type на наш холст и превратим их в срезы. Теперь мы можем делать именно то, что элемент изначально хотел сделать, а именно выполнять нарезку на основе этих атрибутов.

Если мы нажмем «Мультизаказ», у нас останутся только те, у которых есть несколько заказов, а если мы перейдем к «Одиночному заказу», мы останемся с теми, у кого есть одна покупка.

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

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