Измерения в хранилищах данных: структура и типы

Введение

Структура, которая категоризирует факты и показатели в хранилище данных – измерение в хранилище данных.

Измерение – это структура, которая категоризирует факты и показатели для того, чтобы пользователи могли отвечать на бизнес-вопросы. Обычно используемые измерения – люди, продукты, местоположение и время. (Примечание: Люди и время иногда не моделируются как измерения.) В хранилище данных измерения предоставляют структурированную маркировку для числовых показателей, которые в противном случае не упорядочены. Измерение представляет собой набор данных, состоящий из отдельных, непересекающихся элементов данных. Основные функции измерений тройны: фильтрация, группировка и маркировка. Эти функции часто описываются как "нарезка и кубирование". Типичный пример хранилища данных включает продажи как показатель, а клиент и продукт – как измерения. В каждой продаже клиент покупает продукт. Данные можно "нарезать", исключив всех клиентов, кроме исследуемой группы, а затем "скубировать", группируя по продуктам. Измерения данных подобны категориальным переменным в статистике. Обычно измерения в хранилище данных внутренне организованы в одну или несколько иерархий. "Дата" – это распространенное измерение с несколькими возможными иерархиями:

"Дни (группируются в) Месяцы (которые группируются в) Годы",
"Дни (группируются в) Недели (которые группируются в) Годы",
"Дни (группируются в) Месяцы (которые группируются в) Кварталы (которые группируются в) Годы"
и т.д.

Медленно меняются размеры

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

Тип 0 (Сохранить оригинал): Атрибуты никогда не изменяются. История не ведется. Тип 1 (Перезапись): Старые значения атрибута перезаписываются новыми. История не ведется. Тип 2 (Добавить новую строку): Создается новая строка с указанием даты начала/окончания действия или версии для нового значения. Это позволяет вести историю изменений. Тип 3 (Добавить новый атрибут): Создается новый столбец для хранения нового значения. История ограничена количеством столбцов, выделенных для хранения исторических данных. Тип 4 (Добавить таблицу истории): Текущее значение хранится в одной таблице, а история изменений – в другой. Тип 5 (Комбинированный подход 1 + 4): Комбинация типов 1 и 4. История изменений ведется во второй таблице истории. Тип 6 (Комбинированный подход 1 + 2 + 3): Комбинация типов 1, 2 и 3. История изменений ведется как через отдельные строки, так и через отдельные атрибуты. Тип 7 (Гибридный подход): Используются как суррогатный, так и естественный ключи.

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

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

Размер мусорной части

Нежелательное измерение — это удобная группировка флагов и индикаторов, обычно имеющих низкую кардинальность. Создавая абстрактное измерение, эти флаги и индикаторы удаляются из таблицы фактов и помещаются в полезную размерную структуру. Нежелательное измерение — это таблица измерений, состоящая из атрибутов, которые не относятся ни к таблице фактов, ни к каким-либо существующим таблицам измерений. Эти атрибуты обычно представляют собой текст или различные флаги, например, нетипичные комментарии или простые индикаторы «да/нет» или «истина/ложь». Такие атрибуты обычно остаются после того, как все очевидные измерения в бизнес-процессе были определены, и дизайнеру приходится решать, где разместить эти атрибуты, не подходящие к другим измерениям. Одним из решений является создание нового измерения для каждого оставшегося атрибута, но из-за их природы это может потребовать создания огромного количества новых измерений, что приведет к таблице фактов с большим количеством внешних ключей. Дизайнер также может решить оставить оставшиеся атрибуты в таблице фактов, но это может неоправданно увеличить длину строки таблицы, особенно если атрибут представляет собой длинную текстовую строку. Решением этой проблемы является определение всех атрибутов и помещение их в одно или несколько нежелательных измерений. Одно нежелательное измерение может содержать несколько индикаторов «истина/ложь» или «да/нет», не связанных друг с другом, поэтому было бы удобно преобразовать эти индикаторы в более описательные атрибуты. Например, индикатор о прибытии посылки вместо «да» или «нет» можно преобразовать в «прибыла» или «в ожидании» в нежелательном измерении. Дизайнер может создать таблицу измерений так, чтобы она содержала все индикаторы, возникающие в сочетании с каждым другим индикатором, охватывая все возможные комбинации. Это задает фиксированный размер таблицы, равный 2<sup>x</sup> строк, где x — количество индикаторов. Это решение подходит, когда ожидается большое количество различных комбинаций и когда количество возможных комбинаций ограничено приемлемым уровнем. Если количество индикаторов велико, что приводит к созданию очень большой таблицы, или если дизайнер ожидает встретить лишь несколько возможных комбинаций, более целесообразно создавать каждую строку в нежелательном измерении по мере появления новых комбинаций. Для ограничения размера таблиц в других ситуациях может быть уместно использовать несколько нежелательных измерений в зависимости от корреляции между различными индикаторами. Нежелательные измерения также подходят для размещения атрибутов, таких как нетипичные комментарии из таблицы фактов. Такие атрибуты могут состоять из данных из необязательного поля комментариев при размещении заказа клиентом и, следовательно, во многих случаях будут пустыми. Поэтому нежелательное измерение должно содержать одну строку, представляющую пустые значения в виде суррогатного ключа, который будет использоваться в таблице фактов для каждой строки с пустым полем комментария.

A junk dimension is a convenient grouping of typically low cardinality flags and indicators. By creating an abstract dimension, these flags and indicators are removed from the fact table while placing them into a useful dimensional framework. A junk dimension is a dimension table consisting of attributes that do not belong in the fact table or in any of the existing dimension tables. The nature of these attributes is usually text or various flags, e. g. non generic comments or just simple yes/no or true/false indicators. These kinds of attributes are typically remaining when all the obvious dimensions in the business process have been identified and thus the designer is faced with the challenge of where to put these attributes that do not belong in the other dimensions. One solution is to create a new dimension for each of the remaining attributes, but due to their nature, it could be necessary to create a vast number of new dimensions resulting in a fact table with a very large number of foreign keys. The designer could also decide to leave the remaining attributes in the fact table but this could make the row length of the table unnecessarily large if, for example, the attribute is a long text string. The solution to this challenge is to identify all the attributes and then put them into one or several junk dimensions. One junk dimension can hold several true/false or yes/no indicators that have no correlation with each other, so it would be convenient to convert the indicators into a more describing attribute. An example would be an indicator about whether a package had arrived: instead of indicating this as “yes” or “no”, it would be converted into "arrived" or "pending" in the junk dimension. The designer can choose to build the dimension table so it ends up holding all the indicators occurring with every other indicator so that all combinations are covered. This sets up a fixed size for the table itself which would be 2x rows, where x is the number of indicators. This solution is appropriate in situations where the designer would expect to encounter a lot of different combinations and where the possible combinations are limited to an acceptable level. In a situation where the number of indicators are large, thus creating a very big table or where the designer only expects to encounter a few of the possible combinations, it would be more appropriate to build each row in the junk dimension as new combinations are encountered. To limit the size of the tables, multiple junk dimensions might be appropriate in other situations depending on the correlation between various indicators. Junk dimensions are also appropriate for placing attributes like non generic comments from the fact table. Such attributes might consist of data from an optional comment field when a customer places an order and as a result will probably be blank in many cases. Therefore, the junk dimension should contain a single row representing the blanks as a surrogate key that will be used in the fact table for every row returned with a blank comment field.

Размер деградации

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

Ролевая игра

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

Размер подвески

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

Уменьшенное измерение

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

Размер календарной даты

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

Использование терминов представления ISO

При ссылке на данные из реестра метаданных, такого как ISO/IEC 11179, термины представления, такие как "Indicator" (логическое значение "истина"/"ложь"), "Code" (набор непересекающихся перечисляемых значений), обычно используются как измерения. Например, в Национальной модели обмена информацией (NIEM) имя элемента данных будет "PersonGenderCode", а перечисляемые значения могут быть "male", "female" и "unknown".