Схема зірки

У комп'ютингу схема зірки є найпростішим стилем схеми вітрин даних і є найпоширенішим підходом для розробки сховищ даних і вітрин просторових даних.[1] Схема зірки містить одну або більше таблиць фактів, що посилаються на будь-яку кількість таблиць розмірностей. Схема зірки є важливим випадком схеми сніжинки і є більш ефективною для обробки простіших запитів.[2]

Схема зірки отримала свою назву через подібність фізичної моделі даних[3] до форми зірки з таблицею фактів у центрі та таблицями розмірностей, які утворюють вершини зірки навколо неї.

Модель

Схема зірки відокремлює дані бізнес-процесів від фактів, які містять вимірювані, кількісні дані про бізнес, і розмірності, які є описовими атрибутами, пов'язаними з даними про факти. Приклади фактичних даних включають ціну продажу, кількість продажів, час, відстань, швидкість і вагу. Відповідні атрибути розмірностей включають моделі продуктів, кольори продуктів, фізичні розміри продуктів, географічні місця розташування та імена продавців.

Схема зірки, яка має багато розмірностей, іноді називається схемою сороконіжки.[4] Коли є розмірності лише декількох атрибутів, хоча їх і простіше підтримувати, проте це призводить до запитів з багатьма приєднаннями таблиць і робить схему зірки менш зручною у використанні.

Таблиці фактів

Таблиці фактів записують вимірювання або показники для конкретної події. Вони, як правило, складаються з числових значень і зовнішніх ключів до розмірних даних, де зберігається описова інформація.[4] Такі таблиці розраховані на низький рівень уніфікованих деталей (називають «зернистістю» або «зерном»), тобто факти можуть записувати події на дуже атомному рівні. Це може призвести до накопичення великої кількості записів у таблиці фактів з плином часу. Таблиці фактів поділяють на три типи:

  • Таблиці фактів транзакцій фіксують факти про певну подію (наприклад, події продажів)
  • Таблиці фактів знімків записують факти в певний момент часу (наприклад, дані облікового запису наприкінці місяця)
  • Таблиці накопичення знімків записують сукупні факти в певний момент часу (наприклад, загальний обсяг продажів за місяць до даного продукту)

Таблицям фактів, як правило, призначаються сурогатні ключі для забезпечення однозначної ідентифікації кожного рядка. Цей ключ є простим первинним ключем.

Таблиці розмірностей

Таблиці розмірностей зазвичай мають відносно невелику кількість записів у порівнянні з таблицями фактів, але кожен запис може мати дуже велику кількість атрибутів для опису даних про факти. Розмірності можуть визначати найрізноманітніші характеристики, але деякі з найбільш поширених атрибутів, визначених таблицями розмірностей, включають:

  • Таблиці розмірностей часу описують час на найнижчому рівні розбиття часу, для якого події записуються у схему зірки.
  • Таблиці розмірностей географічних даних описують місце знаходження, такі як країна, штат або місто.
  • Таблиці розмірностей виробу описують вироби.
  • Таблиці розмірностей співробітників описують працівників, таких як люди, що займаються продажами.
  • Таблиці розмірностей діапазонів описують діапазони часу, грошові одиниці або інші вимірювані величини для спрощення звітування.

Таблицям розмірностей, як правило, призначаються сурогатні первинні ключі, зазвичай цілого типу, що займають один стовпчик. Вони утворюються, як поєднання атрибутів розмірностей, які утворюють природний ключ.

Переваги

Схеми зірки денормалізовані, тобто звичайні правила нормалізації, притаманні транзакційним реляційним базам даних, розмиті під час розробки і реалізації схем. Переваги денормалізації схеми зірки:

  • Більш прості запити — логіка приєднання схеми зірки, як правило, простіша, ніж логіка об'єднання, необхідна для отримання даних з високо нормалізованої транзакційної схеми.
  • Спрощена логіка бізнес-звітності — у порівнянні з високо нормалізованими схемами, схема зірки спрощує загальну логіку бізнес-звітності, як за фіксовані періоди, так і поточну.
  • Збільшення продуктивності запитів — схеми зірки можуть забезпечувати підвищення продуктивності для звітних додатків лише для читання порівняно з високо нормалізованими схемами.
  • Швидкі агрегації — більш прості запити щодо схеми зірки можуть призвести до покращення продуктивності операцій агрегації.
  • Подаючі куби — схеми зірки використовуються всіма системами OLAP для ефективного побудови власних OLAP-кубів; насправді, більшість основних систем OLAP забезпечують режим роботи ROLAP, який може використовувати схему зірки безпосередньо як джерело без створення власної структури куба.

Недоліки

Основний недолік схеми зірки полягає в тому, що цілісність даних не забезпечується належним чином, оскільки вона знаходиться в дуже денормалізованому стані. Одноразові вставки і оновлення можуть призвести до аномалій даних, яких уникають нормалізовано розроблені схеми. Взагалі кажучи, схеми зірки завантажуються у високо контрольованому режимі за допомогою пакетної обробки або майже у реальному часі, щоб компенсувати відсутність захисту, що надається нормалізацією.

Схема зірки також не є такою гнучкою з точки зору аналітичних потреб, як нормалізована модель даних. Нормалізовані моделі дозволяють виконувати будь-які аналітичні запити, якщо вони дотримуються бізнес-логіки, визначеної в моделі. Схема зірки, як правило, більш цілеспрямовані для конкретного перегляду даних, отже, не дозволяють більш складну аналітику. Вони не підтримують відносини типу many-to-many між суб'єктами господарювання — принаймні, не дуже природно. Зазвичай ці співвідношення спрощуються в схемі зірки, щоб відповідати простої розмірної моделі.

Приклад

Схема зірки, що використовується у прикладі запиту.

Розглянемо базу даних продажів, можливо, з мережі магазинів, класифікованої за датою, магазином і виробом. Зображення схеми праворуч є версією схеми зірки зразкової схеми, наведеної в статті про схему сніжинки.

Fact_Sales є таблицею фактів і також є три таблиці розмірностей Dim_Date, Dim_Store та Dim_Product.

Кожна таблиця розмірностей має первинний ключ у своєму Id стовпчику, що відносяться до одного зі стовпців (переглядаються як рядки у прикладі) Fact_Sales таблиці — триколонного первинного (з'єднуючого) ключа (Date_Id, Store_Id, Product_Id). Стовпчик непервинного ключа Units_Sold таблиці фактів у цьому прикладі є мірою або метрикою, яка може бути використана при розрахунках і аналізі. Стовпці непервинних ключів таблиць розмірностей являють собою додаткові атрибути розмірностей (таких як Year у Dim_Date таблиці).

Наприклад, наступний запит відповідає, скільки телевізорів було продано, для кожної марки та країни, у 2019 році: 

SELECT
	P.Brand,
	S.Country AS Countries,
	SUM(F.Units_Sold)

FROM Fact_Sales F
INNER JOIN Dim_Date D    ON (F.Date_Id = D.Id)
INNER JOIN Dim_Store S   ON (F.Store_Id = S.Id)
INNER JOIN Dim_Product P ON (F.Product_Id = P.Id)

WHERE D.Year = 2019 AND  P.Product_Category = 'tv'

GROUP BY
	P.Brand,
	S.Country

Див. також

Примітки

  1. ↑ Dedić, N. and Stanier C., 2016., «An Evaluation of the Challenges of Multilingualism in Data Warehouse Development» in 18th International Conference on Enterprise Information Systems — ICEIS 2016, p. 196.
  2. ↑ DWH Schemas. 2009. Архів оригіналу за 27 лютого 2019. Процитовано 26 лютого 2019.
  3. ↑ C J Date, «An Introduction to Database Systems (Eighth Edition)», p. 708
  4. ↑ а б Ralph Kimball and Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling (Second Edition), p. 393

Посилання