2. Реляційна модель
Залежно від відповіді на запитання, гіперкуб існує як окрема фізична структура або лише як віртуальна модель даних, розрізнюють системи MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) і HOLAP (Hybrid OLAP).
Основою ROLAP-моделі є звичайні, традиційні, реляційні моделі даних.
У ROLAP-системах гіперкуб — це лише користувацький інтерфейс, який емулюється СКДБ на логічному рівні. Дані в сховищі представляються у вигляді моделі, що дістала назву зірка (star schema). Ця модель складається з таблиць двох типів: однієї таблиці досліджуваних даних, тобто фактів (fact table), це — центр зірки; і кількох таблиць, які характеризують певні виміри цих фактів (demension table).
Таблиця фактів містить складовий ключ, який об'єднує всі ключі таблиць вимірів, а також значення показників, що аналізуються. За допомогою цих ключів таблиця фактів зв'язується з таблицями вимірів. На схемі зв'язків таблиця фактів розташовується в центрі, а таблиці вимірів — на вихідних з центра променях, створюючих малюнок зірки. Звідси — і назва моделі (рис. 10.3). Таблиці вимірів виступають як батьківські, а таблиця фактів є підпорядкованою дочірньою таблицею. Орієнтація дуг на моделях сховищ не вказується.
Завдяки простоті зіркоподібної моделі процедура вибору даних дуже ефективна і зручна для кінцевих користувачів.
Таблиця фактів вміщує числові показники (змінні) якогось напряму діяльності компанії чи фірми, наприклад обсяги продажів, прибуток та ін., а також ключі таблиць вимірів. Таблиці вимірів містять додаткові характеристики ключових полів. Як правило, це довідкові текстові дані, наприклад, дані про назву товару, назву його виробника, тип товару тощо. Необхідно зауважити, що дані таблиць вимірів у моделі типу «зірка» можуть бути денормалізовані. Нормалізація даних запобігає виникненню аномалій при внесенні змін до БД. Оскільки дані сховищ даних є незмінними, денормалізоване їх зберігання не зумовить жодних аномалій.
Якщо ж таблиці вимірів нормалізовані, то така модель називається «сніжинкою» (snowflake schema). Тобто в моделі типу «сніжинка» може бути певна ієрархічна підпорядкованість між окремими таблицями вимірів. Таблиці, що приєднуються до таблиць вимірів, називаються консольними (вони виступають як батьківські), а таблиці до яких вони приєднуються, — таблицями-нащадками (потомками). Приклад моделі типу «сніжинка» наведено на рис. 10.4.
Іноді може використовуватись гібридна модель, яка є комбінацією денормалізованої моделі типу «зірка» та нормалізованої моделі типу «сніжинка». При цьому деякі таблиці вимірів будуть присутніми для задоволення різних запитів в обох моделях.
ROLAP-моделі дозволяють зберігати великі обсяги даних, але вони не досить ефективні при виконанні аналітичних операцій. Тому системи, побудовані на реляційних моделях, скоріше розглядаються як інтелектуальні генератори звітів.
Поки що ці системи переважають, оскільки в реляційні моделі вкладені великі інвестиції. До того ж вони більш зрозумілі і звичні і застосовуються в таких сферах, як роздрібна торгівля, телекомунікації, фінанси, де кількість даних велика, а високої ефективності запитів не потрібно.
Для зменшення часу реакції при реалізації запитів у цих системах доцільно використовувати такий спеціальний засіб, як оптимізатор запитів. Він аналізує запит і визначає кращу, з позиції певного критерію, послідовність операцій звертання до сховища даних для його реалізації. Оптимізатори запитів використовують складні алгоритми статистичної обробки, які оперують числом записів у таблиці, діапазонами ключів і т. д.
HOLAP-системи — це комбінований варіант зберігання даних, який використовують обидва типи СКБД. Агрегати даних зберігаються у багатовимірній СКБД, детальні оперативні дані — у реляційній СКБД
10.3 Відмінності проектування сховищ даних від проектування баз даних Проектування сховищ даних має свою особливість і специфіку, що робить цей процес відмінним від проектування баз даних трансакційних систем.
Сховища даних за своїм призначенням не схожі на бази даних OLTP-систем, які обслуговують поточну оперативну діяльність підприємств та організацій. Сховища даних використовуються для підтримки прийняття стратегічних рішень, що дозволяє аналітикам виявляти тенденції, проводити порівняння і прогнозувати майбутні результати.
Системи OLTP не можуть безпосередньо виконувати функції OLAP. Зокрема, в системах OLTP зберігається тільки «моментальний знімок» найостаннішої оперативної інформації, а для аналізу OLAP потрібне знання попередньої історії трансакцій за тривалий період. Бази даних OLTP-систем безперервно поновлюються, проте іноді містять пропуски і помилкові дані; для OLAP потрібні статичні, вичерпні дані, з виправленими помилками. І нарешті, системи OLTP обробляють тисячі (часом мільйони) трансакцій у день; системи OLAP виконують тільки одну трансакцію за один цикл завантаження: коли дані в систему завантажуються в пакетному режимі, але можуть одночасно реалізовувати та охоплювати тисячі запитів у день. (Під трансакцією тут розуміємо операцію, внаслідок якої база даних переходить з одного стану в інший.)
Ці відмінності у функціях бази даних і сховища даних відображено в структурних відмінностях. Основними з них при проектуванні сховищ даних порівняно з проектуванням баз даних є такі:
У базі даних OLTP-систем дані нормалізуються з метою запобігання виникненню аномалій надмірності та порушення цілісності й узгодженості бази даних при внесенні змін до бази даних. Дані в сховищі даних є статичними, тобто в них практично не вносять зміни, тому для сховищ не таке актуальне питання нормалізації.
При проектуванні баз даних не враховуються процедури їх подальшої обробки. При проектуванні сховищ даних потрібно знати і враховувати процедури агрегування даних, причому ступінь узагальнення для різних даних може бути різним.
При проектуванні сховищ даних необхідно враховувати «часовий» фактор, тобто ступінь деталізації фактів.