15. Архітектури сховищ даних

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

Багатовимірна модель даних, яка лежить в основі побудови багатовимірних сховищданих, основана на концепції багатовимірних кубів або гіперкубів. Вони являють собоювпорядковані багатовимірні масиви, які також часто називають OLAP-кубами (OLAP означаєOn-line Analytical Processing – оперативна аналітична обробка). Через це СД побудованих наоснові багатовимірності називають MOLAP (Multidimensional OLAP). Технологія OLAP – цеметодика оперативного отримання потрібної інформації з великих масивів даних іформування відповідних звітів.

Суть багатовимірного представлення даних полягає в наступному. Більшість реальнихбізнес-процесів описуються великим набором показників, властивостей, атрибутів тощо.Наприклад, для опису процесу продажу можуть знадобитися такі відомості, як найменуваннятоварів або їх груп, інформація про постачальника і покупця, місто, де проводилися продажі,про ціни, кількості і суми проданих товарів. Окрім цього, для відстеження процесу в часіпотрібно ввести такий атрибут, як дата та час. Якщо зібрати всю цю інформацію в таблицю,то вона виявиться складною для візуального аналізу і осмислення. Все це здатне остаточнозаплутати і збити з пантелику будь-кого, хто спробує отримати з такої таблиці кориснуінформацію з метою аналізу поточного стану продажів і пошуку шляхів оптимізації процесуторгівлі. Всі ці проблеми виникають по одній простий причині – зберігання в «плоскій»таблиці по суті багатовимірних даних.

В основі багатовимірного представлення даних лежить їх розділення на дві групи –виміри і факти.Виміри – це атрибути, найменування і властивості об’єктів, що беруть участь в деякомубізнес-процесі. Вимірами можуть бути найменування товарів, назви фірм-постачальників іпокупців, ПІБ людей, назви міст тощо. Виміри можуть бути і числовими, якщо відповіднійкатегорії (наприклад, найменуванню товару) поставлений у відповідність числовий код, але убудь-якому випадку це дискретні дані, тобто такі, що приймають значення з обмеженогонабору. Виміри якісно описують досліджуваний бізнес-процес. Факти – це дані, що кількіснохарактеризують бізнес-процес і можуть приймати нескінченну кількість значень. Прикладифактів – ціна товару або виробу, їх кількість, сума продажу або покупок, зарплатаспівробітників, сума кредиту, страхова винагорода тощо.

Багатовимірний куб можна розглядати як систему координат, осями якої є виміри –дата, товар, покупець. По осях відкладатимуться значення вимірів – дати, найменуваннятоварів, назви фірм-покупців, ПІБ фізичних осіб. В такій системі кожному набору значеньвимірів (наприклад, дата-товар-покупець) відповідатиме комірка, в якій можна розміститичислові показники (тобто факти), пов’язані з даним набором. Таким чином, між об’єктамибізнес-процесу та їх числовими характеристиками буде встановлений однозначний зв’язок.

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

• представлення даних у вигляді багатовимірних кубів є більш наочним, ніжсукупність нормалізованих таблиць реляційної моделі, структуру якої представляєтільки адміністратор БД;

• ширші можливості побудови аналітичних запитів до системи, що використовуєБСД;

• використання багатовимірної моделі в деяких випадках дозволяє різко зменшитичас пошуку в БСД, забезпечуючи виконання аналітичних запитів практично врежимі реального часу. Це пов’язано з тим, що агреговані дані обчислюютьсязаздалегідь і зберігаються в багатовимірних кубах разом з деталізованими. Томувитрачати час на обчислення агрегатів при виконанні запиту вже не потрібно;

• формування навіть найскладніших аналітичних запитів до БСД здійснюється безвикористання SQL з боку користувача.

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

На підставі цього можна зробити висновок, що використання систем збереження, воснові яких лежить багатовимірне представлення даних, доцільно в тих випадках, коли об’ємданих порівняно невеликий, а сама багатовимірна модель має стабільний набір вимірів.

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

Реляційна база даних(relational data base) – це сукупність відносин, що містять всюінформацію, яка зберігається в базі. Фізично це виражається в тому, що інформаціязберігається у вигляді двовимірних таблиць, зв’язаних за допомогою ключових полів.Застосування реляційної моделі при створенні СД часто дозволяє отримати рядпереваги, особливо щодо ефективності роботи з великими масивами даних. На основі РСДбудуються ROLAP-системи (Relational OLAP). В основі технології РСД лежить принцип,відповідно до якого виміри зберігаються в плоских таблицях так само, як і в звичайнихреляційних СУБД, а факти (дані, що агрегуються) в окремих спеціальних таблицях цієї жбази даних. При цьому таблиця фактів є «основою» для пов’язаних з нею таблиць вимірів.

Вона містить кількісні характеристики об’єктів і подій, сукупність яких будуть аналізуватися вмайбутньому.На логічному рівні розрізняють дві схеми організації РСД – «зірка» та «сніжинка».

Дана модель даних складається з двох типів таблиць: однієї таблиціфактів (fact table) – центр «зірки» – та декількох таблиць вимірів (dimension table) – промені«зірки». Таблиця фактів зазвичай містить одну або декілька полів числового типу, що даютьчислову характеристику певному аспекту предметної області (наприклад, об’єм продаж дляторгової компанії або сума платежів для банку), і декілька цілочисельних полів-ключів длядоступу до таблиць вимірів. Таблиці вимірів розшифровують ключі, на які посилається таблиця фактів.

Проте розміщення всієї інформації про виміри в одній таблиці не завжди є виправданим.Наприклад, якщо товари, об’єднані в групи, тобто має місце ієрархія, то для кожного товарудоведеться показувати, до якої групи він відноситься, що приведе до багатократногоповторення назв груп. Це не тільки викликає надмірність таблиці, але і підвищує вірогідністьвиникнення суперечностей (якщо, наприклад, один і той же товар помилково віднесуть дорізних груп). Тому, для ефективнішої роботи з ієрархічними вимірами була розробленамодифікація схеми «зірка», яка отримала назву «сніжинка».

Головною відмінністю схеми «сніжинка» (англ. «snowflake schema») є те, що інформаціюпро один вимір можна зберігати в декількох пов’язаних таблицях. Тобто, якщо хоч одна зтаблиць вимірів має пов’язаних з нею одну чи більше таблиць вимірів, то в цьому випадкуматиме місце схема «сніжинка».

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

Що ж стосується переваг та недоліків РСД в цілому, то варто відмітити наступне.До переваг РСД відноситься:

1. практично необмежений об’єм даних, що зберігаються;

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

3. при необхідності додавання нових вимірів даних немає необхідності виконуватискладну фізичну реорганізацію сховища на відмінну, наприклад, відбагатовимірних СД;

4. забезпечується високий рівень захисту даних і хороші можливості розмежуванняправ доступу.

Головним недоліком РСД є можливість розмноження таблиць вимірів, в разівикористання високого рівня ієрархії даних. Крім того, труднощі можуть викликатинетривіальні аналітичні запити, оскільки в цьому випадку доведеться створювати складніSQL-запити.

Таким чином, вибір реляційної моделі при побудові СД доцільний в наступних випадках:

• коли об’єм даних для зберігання є дуже великим (тобто коли багатовимірні СДстають неефективними);

• якщо ієрархія вимірів не є складною;

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

Така модель, що поєднує в собі принципи реляційної і багатовимірної моделей,отримала назву гібридною або HOLAP – Hybrid OLAP. Сховища даних, побудовані на основіHOLAP, називаються гібридними сховищами даних (ГСД).Головним принципом побудови ГСД є те, що деталізовані дані зберігаються в реляційнійструктурі (ROLAP), що дозволяє зберігати великі об’єми даних, а агреговані – вбагатовимірній (MOLAP), що дозволяє збільшити швидкість виконання запитів (оскільки привиконанні аналітичних запитів вже не потрібно обчислювати агрегати).

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

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

Однак зрозуміло, що крім позитивних рис, гібридна модель має і недоліки

Віртуальним сховищем данихназивається система, яка, працюючи з розрізненимиджерелами даних, емулює роботу звичайного сховища даних, витягуючи, трансформуючи іінтегруючи дані безпосередньо в процесі виконання запиту. Часто віртуальні сховища данихназивають динамічними (ДСД) або DOLAP, оскільки формування OLAP-куба відбуваєтьсядинамічно на ПК користувача.

При роботі з ВСД користувач фактично має справу з «ілюзією» сховища даних.Віртуальність означає, що ВСД існує тільки до тих пір, поки працює сама програма, якоюсховище керується. Як тільки вона закривається, віртуальне сховище припиняє своєіснування.

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