При виборі схеми бази даних для сховища даних, сніжинка і зіркові схеми мають тенденцію бути популярним вибором. Це порівняння обговорює придатність схем зірки та сніжинки в різних сценаріях та їх характеристики.
Сніжинка схема | Зіркова схема | |
---|---|---|
Простота обслуговування / зміни | Ніяких надмірностей, тому схеми сніжинок легше підтримувати та змінювати. | Має надлишкові дані, а значить, менш прості в обслуговуванні / зміні |
Простота використання | Більш складні запити і, отже, менш легко зрозуміти | Низька складність запиту та його легко зрозуміти |
Виконання запитів | Більше іноземних ключів і, отже, довший час виконання запитів (повільніше) | Менша кількість сторонніх ключів і, отже, коротший час виконання запиту (швидше) |
Тип сховища даних | Добре використовувати ядро для сховища даних для спрощення складних відносин (багато: багато) | Добре підходить для даних із простими відносинами (1: 1 або 1: багато) |
Приєднується | Більша кількість приєднань | Менше приєднується |
Таблиця розмірів | Схема сніжинки може мати кілька таблиць розмірів для кожного виміру. | Зіркова схема містить лише одну таблицю розмірів для кожного виміру. |
Коли використовувати | Коли розмірна таблиця порівняно велика за розмірами, сніжинка краще, оскільки вона зменшує простір. | Коли таблиця розмірів містить меншу кількість рядків, ми можемо вибрати схему зірки. |
Нормалізація / денормалізація | Таблиці розмірів є у нормованому вигляді, але Таблиця фактів у денормалізованій формі | Таблиці вимірів та фактів є у денормалізованому вигляді |
Модель даних | Підхід знизу вгору | Підхід зверху вниз |
Розглянемо базу даних для роздрібної торгівлі, яка має багато магазинів, в кожному магазині продається безліч товарів багатьох категорій товарів і різних марок. Сховище даних або дані даних для такого роздрібного продавця повинні забезпечити аналітикам можливість запускати звіти про продажі, згруповані за магазином, датою (або місяцем, кварталом чи роком), або категорією продукту чи маркою.
Якби цей март даних використовував схему зірки, це виглядало б так:
Приклад схеми зіркиТаблиця фактів була б записом операцій з продажу, в той час як є таблиці розмірів для дати, магазину та товару. Таблиці розмірів підключаються до таблиці фактів за допомогою свого первинного ключа, який є зовнішнім ключем для таблиці фактів. Наприклад, замість збереження фактичної дати транзакції у рядку таблиці фактів зберігається date_id. Цей date_id відповідає унікальному рядку в таблиці Dim_Date, і він також зберігає інші атрибути дати, необхідні для групування у звітах. наприклад, день тижня, місяць, квартал року тощо. Дані денормалізовані для легшого звітування.
Ось як можна отримати звіт про кількість телевізорів, що продаються за маркою та країною за допомогою внутрішніх приєднань.
Цей же сценарій також може використовувати схему сніжинки, і в такому випадку вона буде структурована таким чином:
Приклад схеми сніжинки (натисніть, щоб збільшити)Основна відмінність порівняно зі зірковою схемою полягає в тому, що дані в розмірних таблицях більш нормалізовані. Наприклад, замість того, щоб зберігати місяць, квартал та день тижня в кожному рядку таблиці Dim_Date, вони далі розбиваються на власні таблиці розмірів. Аналогічно для таблиці Dim_Store держава та країна є географічними атрибутами, які видалено на один крок - замість того, щоб зберігатись у таблиці Dim_Store, вони тепер зберігаються в окремій таблиці Dim_Geography.
Той самий звіт - кількість телевізорів, проданих по країні та за маркою - зараз трохи складніший, ніж у зірковій схемі:
SQL-запит, щоб отримати кількість продуктів, що продаються за країною та брендом, коли база даних використовує схему сніжинки.