schema types data warehouse modeling star snowflake schema
Цей посібник пояснює різні типи схем складу даних. Дізнайтеся, що таке схема зірок та схема сніжинок та різниця між схемою зірка проти схеми сніжинки:
У цьому Підручники зі складу дат для початківців , ми глибоко розглянули Розмірна модель даних у сховищі даних у нашому попередньому уроці.
У цьому посібнику ми дізнаємося все про схеми сховища даних, які використовуються для структурування таблиць даних (або) таблиць сховищ даних.
як відкрити банку з
Давайте розпочнемо!!
Цільова аудиторія
- Розробники та тестувальники сховища даних / ETL.
- Фахівці з баз даних, що володіють базовими знаннями понять баз даних
- Адміністратори баз даних / експерти з великих даних, які хочуть зрозуміти області зберігання даних / ETL.
- Випускники коледжів / курси підвищення кваліфікації, які шукають роботу зі сховищем даних.
Що ви дізнаєтесь:
Схема сховища даних
У сховищі даних схема використовується для визначення способу організації системи з усіма сутностями бази даних (таблицями фактів, таблицями розмірів) та їх логічним об'єднанням.
Ось різні типи схем у DW:
- Розклад зірок
- Схема SnowFlake
- Діаграма галактики
- Схема скупчення зірок
# 1) Розклад зірок
Це найпростіша та найефективніша схема в сховищі даних. Таблиця фактів у центрі, оточена таблицями з кількома розмірами, нагадує зірку в моделі зіркової схеми.
Таблиця фактів підтримує співвідношення 'один до багатьох' з усіма таблицями розмірностей. Кожен рядок таблиці фактів пов'язаний зі своїми рядками таблиці розмірностей із посиланням на зовнішній ключ.
Через вищевказану причину навігація між таблицями в цій моделі є простою для запитів зведених даних. Кінцевий користувач може легко зрозуміти цю структуру. Отже, всі інструменти бізнес-аналітики (BI) значною мірою підтримують модель схеми Star.
При розробці схем зірок таблиці розмірів цілеспрямовано денормуються. Вони широкі, мають багато атрибутів для зберігання контекстних даних для кращого аналізу та звітності.
Переваги зіркової схеми
- Запити використовують дуже прості об’єднання під час отримання даних, завдяки чому продуктивність запитів підвищується.
- Отримати дані для звітності просто в будь-який момент часу за будь-який період.
Недоліки зіркової схеми
- Якщо у вимогах є багато змін, існуючу схему зірок не рекомендується змінювати та використовувати повторно в довгостроковій перспективі.
- Надлишковість даних - це більше, оскільки таблиці не розділені ієрархічно.
Приклад схеми зірок наведено нижче.
Запит на схему зірки
Кінцевий користувач може запитувати звіт за допомогою інструментів бізнес-аналітики. Усі такі запити оброблятимуться шляхом внутрішнього створення ланцюжка “SELECT запитів”. Виконання цих запитів вплине на час виконання звіту.
З наведеного вище прикладу схеми Star, якщо бізнес-користувач хоче знати, скільки романів і DVD-дисків було продано в штаті Керала в січні 2018 року, тоді ви можете застосувати запит, як показано нижче, у таблицях схеми Star:
SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Product pdim, Sales sfact, Store sdim, Date ddim WHERE sfact.product_id = pdim.product_id AND sfact.store_id = sdim.store_id AND sfact.date_id = ddim.date_id AND sdim.state = 'Kerala' AND ddim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name Результати:
| Назва продукту | Кількість_Продано | |
|---|---|---|
| 7 | Будь-хто може легко зрозуміти та розробити схему. | Важко зрозуміти та розробити схему. |
| Романи | 12 702 | |
| DVD | 32 919 |
Сподіваюся, ви зрозуміли, наскільки легко запитувати схему зірок.
# 2) Схема SnowFlake
Зіркова схема діє як вхідні дані для проектування схеми SnowFlake. Снігові відшарування - це процес, який повністю нормалізує всі таблиці розмірностей зі схеми зірок.
Розташування таблиці фактів у центрі, оточене безліччю ієрархій розмірних таблиць, виглядає як SnowFlake у моделі схеми SnowFlake. Кожен рядок таблиці фактів пов'язаний зі своїми рядками таблиці розмірностей із посиланням на зовнішній ключ.
Під час проектування схем SnowFlake таблиці розмірів цілеспрямовано нормалізуються. Зовнішні ключі будуть додані до кожного рівня таблиць розмірів для посилання на його батьківський атрибут. Складність схеми SnowFlake прямо пропорційна рівням ієрархії таблиць розмірностей.
Переваги схеми SnowFlake:
- Надмірність даних повністю видаляється шляхом створення нових таблиць розмірів.
- У порівнянні із зірковою схемою таблиці розмірів Snow Flaking використовують менше місця.
- Легко оновити (або) підтримувати таблиці Snow Flaking.
Недоліки схеми SnowFlake:
- Через нормалізовані таблиці розмірів система ETL повинна завантажувати кількість таблиць.
- Для виконання запиту вам можуть знадобитися складні об’єднання через кількість доданих таблиць. Отже, продуктивність запитів буде погіршена.
Приклад схеми SnowFlake наведено нижче.
Таблиці розмірів на наведеній вище схемі SnowFlake нормалізовані, як пояснено нижче:
- Вимір дати нормується на квартальні, щомісячні та щотижневі таблиці, залишаючи ідентифікатори зовнішнього ключа в таблиці Дат.
- Розмір сховища нормується, щоб містити таблицю для стану.
- Розмір товару нормується на Бренд.
- У вимірі Клієнт атрибути, підключені до міста, переміщуються до нової таблиці Міста, залишаючи ідентифікатор зовнішнього ключа в таблиці Клієнта.
Таким же чином один вимір може підтримувати кілька рівнів ієрархії.
Різні рівні ієрархій із наведеної діаграми можна згадати наступним чином:
- Щоквартальний ідентифікатор, щомісячний ідентифікатор та щотижневі ідентифікатори - це нові сурогатні ключі, які створюються для ієрархій вимірювання дати, і вони були додані як зовнішні ключі до таблиці вимірів дати.
- Ідентифікатор стану - це новий сурогатний ключ, створений для ієрархії розмірів Store, і він був доданий як зовнішній ключ до таблиці розмірів Store.
- Ідентифікатор бренда - це новий сурогатний ключ, створений для ієрархії вимірів продукту, і він був доданий як зовнішній ключ до таблиці вимірів продукту.
- Ідентифікатор міста - це новий сурогатний ключ, створений для ієрархії вимірів клієнта, і він був доданий як зовнішній ключ у таблицю вимірів клієнта.
Запит схеми сніжинки
Ми можемо генерувати такі самі звіти для кінцевих користувачів, як і зоряні структури схем із схемами SnowFlake. Але запити тут дещо складні.
З наведеного вище прикладу схеми SnowFlake ми збираємося генерувати той самий запит, який ми розробили під час прикладу запиту схеми Star.
Тобто, якщо бізнес-користувач хоче знати, скільки романів і DVD-дисків було продано в штаті Керала в січні 2018 року, ви можете застосувати запит, як показано нижче в таблицях схем SnowFlake.
SELECT pdim.Name Product_Name, Sum (sfact.sales_units) Quanity_Sold FROM Sales sfact INNER JOIN Product pdim ON sfact.product_id = pdim.product_id INNER JOIN Store sdim ON sfact.store_id = sdim.store_id INNER JOIN State stdim ON sdim.state_id = stdim.state_id INNER JOIN Date ddim ON sfact.date_id = ddim.date_id INNER JOIN Month mdim ON ddim.month_id = mdim.month_id WHERE stdim.state = 'Kerala' AND mdim.month = 1 AND ddim.year = 2018 AND pdim.Name in (‘Novels’, ‘DVDs’) GROUP BY pdim.Name Результати:
| Назва продукту | Кількість_Продано |
|---|---|
| Романи | 12 702 |
| DVD | 32 919 |
Окуляри, які слід пам’ятати під час запиту таблиць зі зірками (або) SnowFlake
Будь-який запит може бути розроблений із наведеною нижче структурою:
Речення SELECT:
- Атрибути, зазначені у пункті select, відображаються в результатах запиту.
- Оператор Select також використовує групи для пошуку агрегованих значень, а отже, ми повинні використовувати групу за реченням в умові where.
Пункт FROM:
- Усі основні таблиці фактів та таблиці розмірів повинні бути обрані відповідно до контексту.
Пункт WHERE:
- Відповідні атрибути розмірності згадуються у реченні where шляхом об’єднання з атрибутами таблиці фактів. Сурогатні ключі з таблиць розмірностей поєднуються з відповідними зовнішніми ключами з таблиць фактів для фіксації діапазону даних, які потрібно запитувати. Будь ласка, зверніться до написаного вище прикладу схеми зіркової схеми, щоб зрозуміти це. Ви також можете відфільтрувати дані у самому реченні from, якщо ви використовуєте там внутрішні / зовнішні об'єднання, як написано у прикладі схеми SnowFlake.
- Атрибути виміру також згадуються як обмеження даних у реченні where.
- Фільтруючи дані з усіма описаними вище кроками, відповідні дані повертаються для звітів.
Відповідно до потреб бізнесу, ви можете додати (або) видалити факти, розміри, атрибути та обмеження до зіркової схеми (або) запиту схеми SnowFlake, дотримуючись наведеної вище структури. Ви також можете додавати підзапити (або) об'єднувати різні результати запитів, щоб генерувати дані для будь-яких складних звітів.
# 3) Діаграма Галактики
Схема галактики також відома як схема сузір'я фактів. У цій схемі декілька таблиць фактів мають однакові таблиці вимірів. Розташування таблиць фактів та таблиць розмірностей виглядає як сукупність зірок у моделі схеми Галактики.
Спільні розміри в цій моделі відомі як відповідні розміри.
Цей тип схеми використовується для складних вимог та для сукупних таблиць фактів, які є більш складними для підтримки схеми Star (або) схеми SnowFlake. Цю схему важко підтримувати через її складність.
Приклад схеми галактики наведено нижче.
# 4) Схема скупчення зірок
Схема SnowFlake з багатьма таблицями розмірностей може потребувати більш складних об'єднань під час запиту. Зіркова схема з меншою кількістю таблиць розмірів може мати більшу надмірність. Отже, схема зіркового скупчення з’явилася на зображенні, поєднавши ознаки двох наведених вище схем.
Зіркова схема є основою для розробки схеми зоряного кластера, і кілька основних таблиць розмірів із зіркової схеми оброблені сніжинками, і це, в свою чергу, утворює більш стабільну структуру схеми.
Приклад схеми зоряного скупчення наведено нижче.
Що краще схема сніжинки чи зірка?
Платформа сховища даних та інструменти BI, що використовуються у вашій системі DW, відіграватимуть життєво важливу роль у виборі відповідної схеми, яка буде розроблена. Зірка та SnowFlake - це найбільш часто використовувані схеми в DW.
Зіркова схема є кращою, якщо інструменти BI дозволяють бізнес-користувачам легко взаємодіяти зі структурами таблиць за допомогою простих запитів. Схема SnowFlake є кращою, якщо інструменти BI ускладнюються для бізнес-користувачів безпосередньо взаємодіяти зі структурами таблиць через більше об’єднань та складних запитів.
Ви можете продовжувати використовувати схему SnowFlake, якщо ви хочете заощадити трохи місця для зберігання, або якщо ваша система DW має оптимізовані інструменти для проектування цієї схеми.
Зіркова схема проти схеми сніжинки
Нижче наведені ключові відмінності між схемою Зірка та Снігова Флака.
| С.Ні | Розклад зірок | Схема снігової пластівці |
|---|---|---|
| 1 | Надлишку даних більше. | Надмірність даних менша. |
| два | Місце для зберігання таблиць розмірів більше. | Місце для зберігання розмірних таблиць порівняно менше. |
| 3 | Містить денормалізовані таблиці розмірів. | Містить таблиці нормованих розмірів. |
| 4 | Одиночна таблиця фактів оточена таблицями з кількома розмірами. | Одиночна таблиця фактів оточена безліччю ієрархій таблиць розмірів. |
| 5 | Запити використовують прямі об’єднання між фактами та вимірами для отримання даних. | Запити використовують складні об’єднання між фактом і вимірами для отримання даних. |
| 6 | Час виконання запиту менше. | Час виконання запиту більше. |
| 8 | Використовує підхід зверху вниз. | Використовує підхід знизу вгору. |
Висновок
Ми сподіваємось, ви добре зрозуміли різні типи схем сховища даних, а також їх переваги та недоліки з цього посібника.
Ми також дізналися, як можна перевіряти зіркову схему та схему SnowFlake та яку схему вибрати між цими двома разом із їхніми відмінностями.
Слідкуйте за нашим майбутнім посібником, щоб дізнатися більше про Data Mart в ETL !!
=> Тут слідкуйте за простими навчальними серіями зі зберігання даних.
Рекомендована література
- Типи даних Python
- Типи даних C ++
- Підручник з тестування сховища даних із прикладами | Посібник з тестування ETL
- Топ-10 популярних засобів зберігання даних та технологій тестування
- Вимірна модель даних у сховищі даних - Підручник із прикладами
- Підручник з тестування сховища даних ETL (повний посібник)
- Що таке процес ETL (витяг, перетворення, завантаження) у сховищі даних?
- Видобуток даних: процес, методи та основні проблеми аналізу даних