При выборе схемы базы данных для хранилища данных, снежинка и звездные схемы как правило, популярный выбор. Это сравнение обсуждает пригодность схем звезда-снежинка в различных сценариях и их характеристики.
Снежинка Схема | Звездная Схема | |
---|---|---|
Простота обслуживания / изменения | Нет избыточности, поэтому схемы «снежинок» легче поддерживать и изменять. | Имеет избыточные данные и, следовательно, менее прост в обслуживании / изменении |
Простота использования | Более сложные запросы и, следовательно, менее простые для понимания | Низкая сложность запроса и простота понимания |
Производительность запросов | Больше внешних ключей и, следовательно, больше времени выполнения запроса (медленнее) | Меньшее количество внешних ключей и, следовательно, более короткое время выполнения запроса (быстрее) |
Тип хранилища данных | Хорошо использовать для ядра хранилища данных, чтобы упростить сложные отношения (многие: многие) | Подходит для датамаркетов с простыми отношениями (1: 1 или 1: много) |
присоединяется | Чем больше количество Joins | Меньше присоединений |
Таблица размеров | Схема снежинки может иметь более одной таблицы измерений для каждого измерения. | Звездная схема содержит только одну таблицу измерений для каждого измерения. |
Когда использовать | Когда таблица размеров относительно велика, снежинка лучше, так как она уменьшает пространство. | Когда таблица измерений содержит меньшее количество строк, мы можем выбрать схему Star. |
Нормализация / Денормализация | Таблицы измерений представлены в нормализованной форме, а таблица фактов - в нормализованной форме. | Таблицы измерений и фактов представлены в ненормализованной форме. |
Модель данных | Подход «снизу вверх | Нисходящий подход |
Рассмотрим базу данных для розничного продавца, у которого есть много магазинов, причем каждый магазин продает много товаров во многих товарных категориях и различных брендах. Хранилище данных или витрина данных для такого розничного продавца должны предоставить аналитикам возможность составлять отчеты о продажах, сгруппированные по магазинам, дате (или месяцу, кварталу или году), категории продукта или бренду..
Если бы эта витрина данных использовала звездообразную схему, она бы выглядела следующим образом:
Пример звездной схемыТаблица фактов будет записывать транзакции продаж, в то время как есть таблицы измерений для даты, магазина и продукта. Каждая из таблиц измерений связана с таблицей фактов через их первичный ключ, который является внешним ключом для таблицы фактов. Например, вместо сохранения фактической даты транзакции в строке таблицы фактов сохраняется дата_ид. Этот date_id соответствует уникальной строке в таблице Dim_Date, и в этой строке также хранятся другие атрибуты даты, необходимые для группировки в отчетах. например, день недели, месяц, квартал года и т. д. Данные денормализованы для облегчения отчетности.
Вот как можно получить отчет о количестве телевизоров, проданных по брендам и странам с помощью внутренних объединений..
Тот же сценарий также может использовать схему снежинки, в этом случае она будет иметь следующую структуру:
Пример схемы снежинки (нажмите, чтобы увеличить)Основное отличие по сравнению со звездообразной схемой состоит в том, что данные в таблицах измерений более нормализованы. Например, вместо того, чтобы хранить месяц, квартал и день недели в каждой строке таблицы Dim_Date, они далее разбиваются на их собственные таблицы измерений. Аналогично для таблицы Dim_Store состояние и страна являются географическими атрибутами, которые удалены на один шаг - вместо того, чтобы храниться в таблице Dim_Store, они теперь хранятся в отдельной таблице Dim_Geography..
Тот же отчет - количество телевизоров, проданных по странам и брендам - теперь немного сложнее, чем в схеме «звезда»:
SQL-запрос, чтобы получить количество продуктов, проданных по стране и бренду, когда база данных использует схему снежинки.