Ответ на вопрос
Схема звезды
Схе́ма звезды́ (нем. Sternschema) — это особый вид модели данных, цель которой заключается не в нормализации, а в оптимизации для эффективных операций чтения. Основная область применения — хранилища данных и OLAP-приложения.
Название «схема звезды» обусловлено тем, что таблицы расположены в виде звезды: в центре находится фактная таблица, вокруг которой группируются несколько таблиц измерений. Как правило, схема звезды является денормализованной: возможные аномалии и увеличенный объём хранения допускаются ради повышения производительности. Улучшением служит родственная схеме звезды схема снежинки, где, однако, для связывания многоуровневых таблиц измерений требуются операции соединения (join).
Определение и структура
В качестве логической схемы данных для хранилищ данных получила распространение так называемая схема звезды. Эта схема состоит из одной фактной и нескольких таблиц измерений, которые упорядочены вокруг фактной таблицы «лучами» и ссылаются только на одну фактную таблицу. Название схемы происходит от радиального расположения таблиц измерений вокруг центральной фактной.
Каждая таблица измерений находится в соотношении 1:n с фактной таблицей. Связь 1:n реализуется через первичный ключ таблицы измерений и внешний ключ в фактной таблице. Фактная таблица имплицитно интегрирует многие отношения m:n, что приводит к значительной избыточности. Первичный ключ фактной таблицы составляется из первичных ключей соответствующих таблиц измерений, которые одновременно выступают в роли внешних ключей.
Схема звезды позволяет выбирать, агрегировать и анализировать измеряемые значения (факты). Таблицы измерений, как правило, не нормализованы и поэтому остаются денормализованными: между неключевыми атрибутами существуют функциональные зависимости, нарушающие третью нормальную форму (3NF). Однако это нарушение допускается, так как структура данных обеспечивает большую скорость обработки в ущерб целостности данных и экономии места хранения.
Фактные и таблицы измерений
Данные, подлежащие анализу, называются фактами; они обычно хранятся в фактной таблице. Факты также называют метриками, измерениями или ключевыми показателями. Фактные таблицы могут быть очень большими, что требует поэтапной агрегации данных в хранилище и, по истечении определённого срока, их удаления или переноса в архив. Таблицы содержат ключевые или итоговые показатели, производимые из текущей деятельности предприятия и отражающие его экономическую деятельность: например, прибыльность, затраты, доходы, расходы и т. д. Только когда эти показатели сопоставимы друг с другом, они приобретают смысл. Например, показатели продаж по определённому региону для выбранных товаров за заданный период сопоставляются по отдельным измерениям, в которых оценивается экономический результат.
Таблицы измерений, напротив, содержат «описательные» данные. Фактная таблица содержит внешние ключи, ссылающиеся на записи в таблицах измерений, определяющие их значения. Обычно совокупность внешних ключей на таблицы измерений формирует первичный ключ фактной таблицы. Это подразумевает, что каждая комбинация значений измерений встречается в таблице фактов только один раз.
Таблицы измерений относительно статичны и обычно значительно меньше по объёму, чем фактные таблицы. Название «измерение» объясняется тем, что каждая такая таблица представляет собой отдельное измерение многомерного OLAP-куба.
Поскольку между неключевыми атрибутами в таблицах измерений существуют функциональные зависимости, третья нормальная форма также сознательно нарушается. Чтобы привести такие данные к 3NF, таблицу измерений нужно было бы разделить на иерархические подтаблицы, но ради увеличения производительности в схеме звезды этого не делают и принимают возникающую избыточность.
Преимущество разделения фактов и измерений в том, что факты можно анализировать по каждому измерению независимо и генерализованно. OLAP-приложение не требует «знания» о смысле измерения — интерпретация предоставляется пользователю.
При этом объём таблиц измерений также может быть существенным. Фактные таблицы в схеме звезды часто содержат более 10 миллионов записей. Таблицы измерений занимают меньший объём, но для отдельных измерений могут быть весьма велики. Для уменьшения масштабов и ускорения доступа очень большие таблицы измерений могут быть нормализованы с образованием схемы снежинки.
Характеристики схемы звезды
Таблицы измерений
- Первичный ключ для идентификации значений измерений
- Отражение иерархии измерений через атрибуты
- Денормализованы (не нормализованы)
Фактная таблица
- Внешние ключи на таблицы измерений, то есть нижний уровень каждого измерения включается в качестве ключа в фактную таблицу
- Внешние ключи на измерения формируют составной первичный ключ для фактов
Медленно изменяющиеся измерения (Slowly Changing Dimensions)
Медленно меняющиеся измерения (англ. Slowly Changing Dimensions, SCD) — это концепция в хранилищах данных для управления изменениями в атрибутах таблиц измерений с течением времени[1]. Различные типы SCD предлагают разные подходы к отслеживанию исторических данных, что необходимо для корректного исторического анализа[2]. Основоположником классификации считается Ральф Кимбалл[3].
SCD Тип 0: Сохранение оригинала (англ. Retain Original) Этот тип применяется к атрибутам, значения которых никогда не должны меняться, например, дата рождения клиента или дата его первой покупки[4]. Любые изменения в исходных данных игнорируются, и значение в хранилище данных остаётся неизменным[5].
SCD Тип 1: Перезапись (англ. Overwrite) Старое значение атрибута перезаписывается новым, в результате чего история изменений полностью теряется[4]. В таблице хранится только самое актуальное состояние[6]. Преимуществами являются простота реализации и экономия места для хранения, а недостатком — невозможность проводить исторический анализ, так как предыдущие данные утрачиваются[4].
SCD Тип 2: Добавление новой строки (англ. Add New Row) Наиболее распространённый метод, позволяющий сохранять полную историю изменений[4]. При изменении атрибута в таблицу измерения добавляется новая строка с обновлёнными данными, в то время как старая строка помечается как неактуальная[6]. Для отслеживания версий используются дополнительные поля, такие как суррогатный ключ для каждой строки, даты начала и окончания действия записи (англ. effective date) или флаг текущей версии[6]. Применяется для отслеживания смены адреса клиента, должности сотрудника и т. д.[4]
SCD Тип 3: Добавление нового атрибута (англ. Add New Attribute) Метод позволяет отслеживать ограниченную историю изменений путём добавления в таблицу дополнительных столбцов для хранения предыдущих значений[6]. Например, в запись добавляется столбец «Previous_State», в который записывается старое значение атрибута перед его обновлением. Подход позволяет хранить только ограниченное количество исторических версий (чаще всего одну) и подходит для случаев, когда изменения происходят редко[4][5].
SCD Тип 4: Добавление таблицы истории (англ. Add History Table) Подход предполагает использование двух таблиц: основной таблицы измерений, которая хранит только текущие данные (как в SCD Тип 1), и отдельной таблицы истории, в которую записываются все изменения[4]. Атрибуты, которые меняются часто, могут быть вынесены в отдельное «микро-измерение» (англ. mini-dimension), чтобы основная таблица не разрасталась[7].
SCD Тип 5: Гибридный подход (англ. Mini-Dimension and Type 1 Outrigger) Является расширением Типа 4. Он использует «микро-измерение», но при этом в основной таблице измерения хранится ключ, указывающий на текущую версию атрибутов в этом микро-измерении. Этот ключ обновляется по принципу Типа 1 (перезапись)[8]. Название «Тип 5» происходит от комбинации методов: 4 + 1 = 5[8]. Такой подход позволяет анализировать исторические факты с учётом исторических значений атрибутов и одновременно легко получать доступ к их текущим значениям[8].
SCD Тип 6: Комбинированный подход (англ. Combined Approach) Гибрид типов 1, 2 и 3, который позволяет одновременно видеть текущее значение, хранить полную историю и иметь доступ к предыдущему значению[4][9]. В одной строке таблицы измерения сочетаются: перезапись текущего значения в столбце «Current_Value» (Тип 1), добавление новой строки для каждого исторического изменения (Тип 2) и хранение предыдущего значения в отдельном столбце (Тип 3)[10]. Название «Тип 6» символизирует сумму подходов: 1 + 2 + 3 = 6[10].
SCD Тип 7: Гибридный подход с двумя ключами (англ. Hybrid: Dual Type 1 and Type 2) Вариация Типа 6, где измерение логически разделяется на две таблицы: одна для текущих данных (обновляется по Типу 1), а другая — для исторических (обновляется по Типу 2)[11]. Таблица фактов содержит два внешних ключа: один указывает на суррогатный ключ для исторической версии, а другой — на ключ текущей версии[11]. Это обеспечивает гибкость, позволяя аналитикам запрашивать данные как на основе исторического контекста транзакции, так и на основе самого последнего состояния измерения[11].
Преимущества и недостатки
Преимущества
- Высокая производительность запросов: благодаря денормализации таблиц измерений сокращается количество соединений (join), что обеспечивает высокую скорость выполнения аналитических запросов. Это критически важно для интерактивных отчётов и дашбордов[12]. Специальный тип соединения (star join) также хорошо оптимизируется.
- Простота и прозрачность: структура с центральной таблицей фактов и присоединёнными к ней таблицами измерений интуитивно понятна для бизнес-пользователей[12]. Модель содержит значительно меньше связей, чем разветвлённая схема снежинки, что облегчает как анализ данных, так и модернизацию отчётности.
- Совместимость с BI-инструментами: большинство платформ бизнес-аналитики (BI) оптимизированы для работы со схемой «звезда», что упрощает их интеграцию и настройку[13].
- Управляемость аномалий: аномалии изменения легко контролируются, поскольку данные в таблицах измерений (классификации) обычно меняются редко.
- Относительно небольшой объём хранения: таблицы измерений, как правило, малы по сравнению с таблицами фактов, поэтому дополнительный объём хранения, вызванный денормализацией, в традиционных реализациях считается незначительным.
Недостатки
- Увеличение времени ответа при частых обращениях к очень большим таблицам измерений (функции просмотра/обзора)
- Избыточность внутри одной таблицы измерений вследствие многократного хранения одних и тех же значений или фактов
- Сложности в построении агрегатов
Повышенные затраты на хранение: из-за дублирования данных в денормализованных таблицах измерений схема «звезда» может приводить к более высоким затратам на хранение. Это особенно актуально для облачных платформ, где стоимость напрямую зависит от объёма хранимых данных[14].
Схема звезды и схема снежинки
| Схема звезды | Схема снежинки | |
|---|---|---|
| Цель |
|
|
| Результат |
|
|
| Производительность и стоимость в облачных СУБД |
|
|
Практическое применение
Диаграмма требований
1. Сбор бизнес-требований:
Построение схемы звезды начинается с вопросов:
Какие факты интересуют и по каким критериям?
Доступные данные, требуемые отчёты и содержание таблиц
2. Построение диаграммы требований:
Определённые спецификации отображаются на диаграмме требований.
Необходимые показатели:
- Атрибуты, характеризующие результат работы бизнес-единицы
- Вопрос: Насколько хорошо?
Измерения:
- Атрибуты, по которым измеряются показатели
- Вопросы: Что? Когда? Где?
Категории:
- Диапазоны значений измерения
- Вопрос: Насколько точно?
Star Join
Схема звезды приводит к типичным запросам с использованием «звёздного соединения» (Star Join), которые выглядят следующим образом:
SELECT Атрибуты измерений, SUM(Фактов)
FROM Фактная_таблица
INNER JOIN Таблица_измерения
[INNER JOIN дополнительные таблицы измерений]
WHERE Условие
GROUP BY Атрибут_измерения
ORDER BY Агрегация_фактов или Атрибут_измерения
Пример
В качестве примера рассмотрим запрос для анализа данных о продажах с целью получения общей выручки по категориям товаров и регионам для всех транзакций, совершённых после 31 декабря 2020 года. Такой запрос объединяет центральную таблицу фактов с несколькими таблицами измерений[15].
Для примера используется следующая структура таблиц:
- 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: Запрос начинается с центральной таблицы фактов[15].INNER JOIN: Используется для соединения таблицы фактов с таблицами измерений по соответствующим ключам[16].WHERE dd.FullDate > '2020-12-31': Ключевое условие для фильтрации, которое отбирает только записи после 2020 года.SUM(fs.Quantity * fs.Price): Вычисляется метрика — общая выручка.GROUP BY dp.Category, dc.Region: Результаты агрегируются по категориям товаров и регионам клиентов для получения суммарных данных в нужных разрезах[17].ORDER BY TotalRevenue DESC: Результаты сортируются для отображения наиболее прибыльных групп.
Оптимизаторы баз данных часто распознают подобный шаблон «звёздного соединения» и применяют для его обработки специализированные планы выполнения[18]. Число используемых соединений в схеме звезды не зависит от длины пути агрегации, в отличие от схемы снежинки.
Роль в современных архитектурах данных
Несмотря на появление Big Data и развитие облачных платформ, схема «звезда» сохраняет актуальность, однако её роль эволюционировала: если в классических хранилищах она составляла ядро системы, то в современных многоуровневых архитектурах занимает место презентационного слоя (витрины данных) для конечных пользователей и аналитических инструментов. В Data Lake она часто применяется как логический семантический слой для структурирования данных и придания им бизнес-контекста[19].
В гибридных моделях схема «звезда» используется в тандеме с методологией Data Vault: Data Vault служит гибким, масштабируемым и легко поддающимся аудиту интеграционным слоем, объединяющим данные из различных источников[20][21]. На его основе для конкретных бизнес-задач строятся витрины данных (data marts) в виде схемы «звезда»[22].
В архитектурах Data Lakehouse с удешевлением облачного хранения конкуренцию схеме «звезда» иногда составляют широкие денормализованные таблицы («one big table»), упрощающие работу в BI-инструментах[23]. Тем не менее схема «звезда» остаётся одной из доминирующих техник моделирования витрин данных благодаря простоте, высокой производительности запросов и поддержке большинства BI-платформ[24].
Примечания
Литература
- Kimball, R.; Ross, M. The Data Warehouse Toolkit. The Complete Guide to Dimensional Modeling. 2-е изд. New York: John Wiley & Sons, 2002. ISBN 0-471-20024-7. (на англ.)
- Кемпер, А.; Айклер, А. Datenbanksysteme. Eine Einführung. 6-е изд. Мюнхен: Oldenbourg Wissenschaftsverlag, 2006. ISBN 3-486-57690-9.
- Langit, L. Foundations of SQL Server 2005 Business Intelligence. 1-е изд. New York: Apress, 2007. ISBN 978-1-59059-834-4. (на англ.)
- Rob, P.; Coronel, C.; Crockett, K. Database systems: design, implementation & management. London: Cengage Learning, 2008. ISBN 1-84480-732-0. (на англ.)
- Kimball, R.; Ross, M. The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling. 3-е изд. New York: Wiley, 2013. ISBN 978-1-118-53080-1. (на англ.)
- Linstedt, D.; Olshimke, M. Building a Scalable Data Warehouse with Data Vault 2.0. Waltham, MA: Morgan Kaufmann, 2015. ISBN 978-0-12-802648-9. (на англ.)