Схема звезды

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

Каждая таблица измерений находится в соотношении 1:n с фактной таблицей. Связь 1:n реализуется через первичный ключ таблицы измерений и внешний ключ в фактной таблице. Фактная таблица имплицитно интегрирует многие отношения m: n, что приводит к значительной избыточности. Ключ фактной таблицы составляется из первичных ключей соответствующих таблиц измерений, которые одновременно выступают в роли внешних ключей.

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

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

Таблицы измерений, напротив, содержат «описательные» данные. Фактная таблица содержит внешние ключи, ссылающиеся на записи в таблицах измерений, определяющие их значения. Обычно совокупность внешних ключей на таблицы измерений формирует первичный ключ фактной таблицы. Это подразумевает, что каждая комбинация значений измерений встречается в таблице фактов только один раз.
Таблицы измерений относительно статичны и обычно значительно меньше по объёму, чем фактные таблицы. Название «измерение» объясняется тем, что каждая такая таблица представляет собой отдельное измерение многомерного OLAP-куба.

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

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

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

Медленно меняющиеся измерения (англ. Slowly Changing Dimensions, SCD) — это концепция в хранилищах данных для управления изменениями в атрибутах таблиц измерений с течением времени^[3]. Различные типы SCD предлагают разные подходы к отслеживанию исторических данных, что необходимо для корректного исторического анализа^[4]. Основоположником классификации считается Ральф Кимбалл^[5].

SCD Тип 0: Сохранение оригинала (англ. Retain Original) Этот тип применяется к атрибутам, значения которых никогда не должны меняться, например, дата рождения клиента или дата его первой покупки^[6]. Любые изменения в исходных данных игнорируются, и значение в хранилище данных остаётся неизменным^[7].

SCD Тип 1: Перезапись (англ. Overwrite) Старое значение атрибута перезаписывается новым, в результате чего история изменений полностью теряется^[6]. В таблице хранится только самое актуальное состояние^[8]. Преимуществами являются простота реализации и экономия места для хранения, а недостатком — невозможность проводить исторический анализ, так как предыдущие данные утрачиваются^[6].

SCD Тип 2: Добавление новой строки (англ. Add New Row) Наиболее распространённый метод, позволяющий сохранять полную историю изменений^[6]. При изменении атрибута в таблицу измерения добавляется новая строка с обновлёнными данными, в то время как старая строка помечается как неактуальная^[8]. Для отслеживания версий используются дополнительные поля, такие как суррогатный ключ для каждой строки, даты начала и окончания действия записи (англ. effective date) или флаг текущей версии^[8]. Применяется для отслеживания смены адреса клиента, должности сотрудника и т. д^[6]

SCD Тип 3: Добавление нового атрибута (англ. Add New Attribute) Метод позволяет отслеживать ограниченную историю изменений путём добавления в таблицу дополнительных столбцов для хранения предыдущих значений^[8].. Например, в запись добавляется столбец «Previous_State», в который записывается старое значение атрибута перед его обновлением. Подход позволяет хранить только ограниченное количество исторических версий (чаще всего одну) и подходит для случаев, когда изменения происходят редко^[6][7].

SCD Тип 4: Добавление таблицы истории (англ. Add History Table) Подход предполагает использование двух таблиц: основной таблицы измерений, которая хранит только текущие данные (как в SCD Тип 1), и отдельной таблицы истории, в которую записываются все изменения^[6]. Атрибуты, которые меняются часто, могут быть вынесены в отдельное «микро-измерение» (англ. mini-dimension), чтобы основная таблица не разрасталась^[9].

SCD Тип 5: Гибридный подход (англ. Mini-Dimension and Type 1 Outrigger) Является расширением Типа 4. Он использует «микро-измерение», но при этом в основной таблице измерения хранится ключ, указывающий на текущую версию атрибутов в этом микро-измерении. Этот ключ обновляется по принципу Типа 1 (перезапись)^[10]. Название «Тип 5» происходит от комбинации методов: 4 + 1 = 5^[10]. Такой подход позволяет анализировать исторические факты с учётом исторических значений атрибутов и одновременно легко получать доступ к их текущим значениям^[10].

SCD Тип 6: Комбинированный подход (англ. Combined Approach) Гибрид типов 1, 2 и 3, который позволяет одновременно видеть текущее значение, хранить полную историю и иметь доступ к предыдущему значению^[6][11]. В одной строке таблицы измерения сочетаются: перезапись текущего значения в столбце «Current_Value» (Тип 1), добавление новой строки для каждого исторического изменения (Тип 2) и хранение предыдущего значения в отдельном столбце (Тип 3)^[12]. Название «Тип 6» символизирует сумму подходов: 1 + 2 + 3 = 6^[12].

SCD Тип 7: Гибридный подход с двумя ключами (англ. Hybrid: Dual Type 1 and Type 2) Вариация Типа 6, где измерение логически разделяется на две таблицы: одна для текущих данных (обновляется по Типу 1), а другая — для исторических (обновляется по Типу 2)^[13]. Таблица фактов содержит два внешних ключа: один указывает на суррогатный ключ для исторической версии, а другой — на ключ текущей версии^[13]. Это обеспечивает гибкость, позволяя аналитикам запрашивать данные как на основе исторического контекста транзакции, так и на основе самого последнего состояния измерения^[13].

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

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

• Высокая производительность запросов: благодаря денормализации таблиц измерений сокращается количество соединений (join), что обеспечивает высокую скорость выполнения аналитических запросов. Это критически важно для интерактивных отчётов и дашбордов^[14]. Специальный тип соединения (star join) также хорошо оптимизируется.
• Простота и прозрачность: структура с центральной таблицей фактов и присоединёнными к ней таблицами измерений интуитивно понятна для бизнес-пользователей^[14]. Модель содержит значительно меньше связей, чем разветвлённая схема снежинки, что облегчает как анализ данных, так и модернизацию отчётности.
• Совместимость с BI-инструментами: большинство платформ бизнес-аналитики (BI) оптимизированы для работы со схемой «звезда», что упрощает их интеграцию и настройку^[15].
• Управляемость аномалий: аномалии изменения легко контролируются, поскольку данные в таблицах измерений (классификации) обычно меняются редко.
• Относительно небольшой объём хранения: таблицы измерений, как правило, малы по сравнению с таблицами фактов, поэтому дополнительный объём хранения, вызванный денормализацией, в традиционных реализациях считается незначительным.

• Увеличение времени ответа при частых обращениях к очень большим таблицам измерений (функции просмотра/обзора)
• Избыточность внутри одной таблицы измерений вследствие многократного хранения одних и тех же значений или фактов
• Сложности в построении агрегатов
• Повышенные затраты на хранение: из-за дублирования данных в денормализованных таблицах измерений схема «звезда» может приводить к более высоким затратам на хранение. Это особенно актуально для облачных платформ, где стоимость напрямую зависит от объёма хранимых данных^[16].

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

В архитектуре Data Lake, где хранятся большие объёмы неструктурированных и полуструктурированных данных, схема «звезда» часто применяется в качестве логического семантического слоя. Она помогает структурировать данные и придать им бизнес-контекст, делая их доступными для анализа.

В гибридных моделях схема «звезда» часто используется в тандеме с методологией Data Vault. В таких архитектурах Data Vault служит для создания гибкого, масштабируемого и легко поддающегося аудиту интеграционного слоя, который объединяет данные из различных источников^[17][18]. На основе этого слоя для конкретных бизнес-задач и отделов строятся витрины данных (data marts) в виде схемы «звезда», которые предоставляют данные для отчётности и анализа.

В контексте современных архитектур, таких как Data Lakehouse, и с удешевлением облачного хранения данных, конкуренцию схеме «звезда» в некоторых случаях составляют широкие денормализованные таблицы (иногда называемые «one big table»), которые упрощают работу для конечных пользователей в BI-инструментах^[19]. Тем не менее, схема «звезда» остаётся одной из доминирующих техник моделирования для создания витрин данных благодаря своей простоте, высокой производительности запросов и оптимальной поддержке со стороны большинства BI-платформ^[20].

1. Сбор бизнес-требований:
Построение схемы звезды начинается с вопросов:

• Какие факты интересуют и по каким критериям?
• Доступные данные, требуемые отчёты и содержание таблиц

2. Построение диаграммы требований:
Определённые спецификации отображаются на диаграмме требований.

• Необходимые показатели:
  • Атрибуты, характеризующие результат работы бизнес-единицы
  • Вопрос: Насколько хорошо?

• Измерения:
  • Атрибуты, по которым измеряются показатели
  • Вопросы: Что? Когда? Где?

• Категории:
  • Диапазоны значений измерения
  • Вопрос: Насколько точно?

Схема звезды приводит к типичным запросам с использованием «звёздного соединения» (Star Join), которые выглядят следующим образом:

SELECT Атрибуты измерений, SUM(Фактов)
FROM Фактная_таблица
INNER JOIN Таблица_измерения
[INNER JOIN дополнительные таблицы измерений]
WHERE Условие
GROUP BY Атрибут_измерения
ORDER BY Агрегация_фактов или Атрибут_измерения

В качестве примера рассмотрим запрос для анализа данных о продажах с целью получения общей выручки по категориям товаров и регионам для всех транзакций, совершённых после 31 декабря 2020 года. Такой запрос объединяет центральную таблицу фактов с несколькими таблицами измерений^[21].

Для примера используется следующая структура таблиц:

• FactSales (таблица фактов): содержит внешние ключи (DateID, ProductID, CustomerID) и показатели (Quantity, Price).
• DimDate (измерение времени): содержит атрибуты даты, такие как FullDate.
• DimProduct (измерение товаров): содержит атрибуты товаров, такие как Category.
• DimCustomer (измерение клиентов): содержит атрибуты клиентов, такие как Region.

SELECT
    dp.Category AS ProductCategory,
    dc.Region AS CustomerRegion,
    SUM(fs.Quantity * fs.Price) AS TotalRevenue
FROM
    FactSales AS fs
INNER JOIN
    DimDate AS dd ON fs.DateID = dd.DateID
INNER JOIN
    DimProduct AS dp ON fs.ProductID = dp.ProductID
INNER JOIN
    DimCustomer AS dc ON fs.CustomerID = dc.CustomerID
WHERE
    dd.FullDate > '2020-12-31'
GROUP BY
    dp.Category,
    dc.Region
ORDER BY
    TotalRevenue DESC;

Пояснение к запросу:

• FROM FactSales AS fs: Запрос начинается с центральной таблицы фактов^[21].
• INNER JOIN: Используется для соединения таблицы фактов с таблицами измерений по соответствующим ключам^[22].
• WHERE dd.FullDate > '2020-12-31': Ключевое условие для фильтрации, которое отбирает только записи после 2020 года.
• SUM(fs.Quantity * fs.Price): Вычисляется метрика — общая выручка.
• GROUP BY dp.Category, dc.Region: Результаты агрегируются по категориям товаров и регионам клиентов для получения суммарных данных в нужных разрезах^[23].
• ORDER BY TotalRevenue DESC: Результаты сортируются для отображения наиболее прибыльных групп.

Оптимизаторы баз данных часто распознают подобный шаблон «звёздного соединения» и применяют для его обработки специализированные планы выполнения^[24]. Число используемых соединений в схеме звезды не зависит от длины пути агрегации, в отличие от схемы снежинки.