Вимоги до проектування сховищ даних

До проектування сховищ даних висуваються такі вимоги :

структура даних повинна бути зрозуміла користувачам;

повинні бути виділені статичні дані, які модифікуються за розкладом: щодня, щотижня, щоквартально;

повинні бути спрощені вимоги до запитів з метою виключення запитів, які могли б вимагати множинних тверджень SQL у традиційних реляційних СУБД;

повинна бути забезпечена підтримка складних запитів SQL, які потребують послідовної обробки тисяч або мільйонів записів. Ці вимоги істотно відрізняють структуру реляційних СУБД і сховищ даних.

Інформація, що завантажується в сховище, повинна інтегруватися в цілісну структуру, що відповідає цілям аналізу даних. При цьому мінімізуються невідповідності між даними з різних оперативних систем. Дані інтегровані на безлічі рівнів: на рівні ключа, атрибуту, на описовому, структурному рівні. Загальні дані і загальна обробка даних консолідовані і є однаковим для всіх даних, які подібні або схожі в сховищі даних. Інформація структурується за різними рівнями деталізації:

висока ступінь суммарізаціі;

низький ступінь суммарізаціі;

потокова детальна інформація.

Сховища можна розглядати як набір моментальних знімків стану даних: можна відновити картинку в будь-який момент часу. Атрибут часу завжди явно присутній в структурах даних сховища.

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

Нормалізація даних у реляційних СУБД призводить до створення безлічі пов'язаних між собою таблиць. У результаті виконання складних запитів неминуче призводить до об'єднання багатьох таблиць, що істотно збільшує час відгуку. Проектування сховища даних передбачає створення денормалізованої структури даних (допускається надмірність даних і можливість виникнення аномалій при маніпулюванні даними), орієнтованої в першу чергу на високу продуктивність при виконанні аналітичних запитів. Нормалізація робить модель сховища занадто складною, ускладнює її розуміння і погіршує ефективність виконання запиту.

Сучасні підходи до моделювання сховищ даних поділяються на два основних класи:

традиційне ER-моделювання (Білла Інмона);

багатовимірне моделювання (Ральфа Кімбала).

Використання першого підходу дозволяє найбільш повно описати предметні області бізнесу організації і організувати зберігання історичної інформації. Другий підхід дозволяє досить швидко побудувати модель для аналізу різних показників, проте має низку недоліків (наприклад, постійні компроміси при виборі способу зберігання історичних даних).

Для ефективного ER-проектування сховищ даних використовується розмірна модель (Dimensional).

Dimensional – методологія проектування, спеціально призначена для розробки сховищ даних. Моделювання Dimensional схоже з моделюванням зв'язків і сутностей для реляційної моделі, але відрізняється цілями. Реляційна модель акцентується на цілісності та ефективності введення даних. Розмірна модель (Dimensional) орієнтована в першу чергу на виконання складних запитів до СД.

Сховища з вимірами використовують схему "зірка" чи схему "сніжинка".

Схема "зірка"

Схема "зірка" – спеціальна організація реляційних таблиць, зручна для зберігання багатовимірних показників. Ця схема забезпечує високу швидкість виконання запиту за допомогою денормалізації і розділення даних. Неможливо створити універсальну денормалізовану структуру даних, що забезпечує високу продуктивність при виконанні будь-якого аналітичного запиту. Тому схема "зірка" будується так, щоб забезпечити найвищу продуктивність при виконанні одного найважливішого запиту або групи схожих запитів.

Схема "зірка" зазвичай містить одну велику таблицю – таблицю факту (fact table), що поміщена в центр, і оточуючі її менші таблиці – таблиці розмірності (dimensional table) – з'єднані з таблицею факту у вигляді зірки радіальними зв'язками. У цих зв'язках таблиці розмірності є батьківськими, таблиця факту – дочірньою.

Перш ніж створити БД зі схемою типу зірки, необхідно проаналізувати бізнес-правила предметної області з метою з'ясування, які дані необхідно накопичувати і аналізувати постійно. Ці дані повинні бути поміщені в таблицю факту.

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

Таблиця факту є центральною таблицею в схемі "зірка". Вона може складатися з мільйонів рядків і містити підсумкові або фактичні дані, які будуть покладені в основу запитів. Вона з'єднує дані, які зберігалися б у багатьох таблицях традиційних реляційних БД. Таблиця факту і таблиці розмірності пов'язані ідентифікованими зв'язками, при цьому первинні ключі таблиці розмірності мігрують у таблицю факту в якості зовнішніх ключів. У розмірній моделі напрямки зв'язків явно не вказуються – вони визначаються типом таблиць.

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

У прикладі таблиця факту містить сумарні дані про продаж товарів ("SALE"), а таблиці розмірності містять дані про замовника і замовленнях ("CUSTOMER"), продуктах ("PRODUCT"), продавцях ("SALESPEOPLE") та періоди часу ("TIME" ).

Рис. 11.2. Схема "зірка"

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

Первинний ключ таблиці факту цілком складається з первинних ключів всіх таблиць розмірності. У прикладі (таблиця факту "SALE") первинний ключ складається з чотирьох зовнішніх ключів: CustomerID, SalespeopleID, TimeID і ProductID.

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

SQL-запит до схеми "зірка" зазвичай містить в собі:

одне або декілька з'єднань таблиці фактів з таблицями розмірності;

кілька фільтрів (SQL-оператор WHERE), що застосовуються до таблиці фактів або таблиць розмірності;

угруповання і агрегування за необхідними елементами ієрархії вимірів (dimension elements).

Схема "сніжинка"

Схема сніжинки дістала таку назву через свою форму, у вигляді якої відображається логічна схема таблиць у багатовимірній БД. Так само як і в схемі зірки, схема сніжинки представлена централізованою таблицею фактів, сполученою з таблицями вимірів. Відмінністю є те, що тут таблиці вимірів нормалізовані з рядом інших пов'язаних вимірювальних таблиць (консольних таблиць), – тоді як в схемі зірки таблиці вимірів повністю денормалізовані. Чим більше міра нормалізації таблиць вимірів, тим складніше виглядає структура схеми сніжинки. Створюваний "ефект сніжинки" стосується лише таблиць вимірів, і не застосовується до таблиць фактів.

Консольні таблиці можуть бути пов'язані тільки таблицями розмірності. Консольна таблиця є батьківською, а таблиця розмірності – дочірньою. Зв'язок може бути ідентифікований або неідентифікований. Консольна таблиця не може бути пов'язана з таблицею факту. Вона використовується для нормалізації даних у таблицях розмірності.

На рис. 11.3. наведено приклад схеми "сніжинка". Крім таблиці факту SALE, та таблиць розмірності (CUSTOMER, PRODUCT, SALESPEOPLE, TIME), схема містить консольні таблиці: PRODUCT_TYPE – типи продуктів, PERIOD – період часу, REGION – регіон.

Рис. 11.3. Схема "сніжинка"

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

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