5. Підходи до проектування сховищ даних

Проектування сховищ даних має свою особливість і специфіку, що робить цей процес відмінним від проектування баз даних трансакційних систем.

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

Системи OLTP не можуть безпосередньо виконувати функції OLAP. Зокрема, в системах OLTP зберігається тільки «моментальний знімок» найостаннішої оперативної інформації, а для аналізу OLAP потрібне знання попередньої історії трансакцій за тривалий період. Бази даних OLTP-систем безперервно поновлюються, проте іноді містять пропуски і помилкові дані; для OLAP потрібні статичні, вичерпні дані, з виправленими помилками. І нарешті, системи OLTP обробляють тисячі (часом мільйони) трансакцій у день; системи OLAP виконують тільки одну трансакцію за один цикл завантаження: коли дані в систему завантажуються в пакетному режимі, але можуть одночасно реалізовувати та охоплювати тисячі запитів у день. (Під трансакцією тут розуміємо операцію, внаслідок якої база даних переходить з одного стану в інший.)

Ці відмінності у функціях бази даних і сховища даних відображено в структурних відмінностях. Основними з них при проектуванні сховищ даних порівняно з проектуванням баз даних є такі:

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

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

3. При проектуванні сховищ даних необхідно враховувати «часовий» фактор, тобто ступінь деталізації фактів.

Існує два способи проектування сховищ даних: спадний і висхідний.

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

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

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

Можна виокремити такі три підходи до проектування сховищ даних : метод реконструкції, проектування за шаблоном, проектування під замовлення.

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

• коли модель OLTP-системи відносно нова та охоплює всі предметні області, для яких планується розробка сховища даних;

• коли багато таблиць фактів та вимірів присутні в моделі бази даних.

Проте цей підхід має теж ряд недоліків. Насамперед переважна більшість сутностей бази даних орієнтована на бізнес-процеси, а не на бізнес-поняття, що вимагає суттєвого перепроектування існуючої моделі до потреб сховища даних. Так, база даних може містити такі сутності, що характеризують бізнес-процеси, як ВІДВАНТАЖЕННЯ та ВИПИСКА. Перша сутність характеризує такий бізнес-процес, як відвантаження продукції споживачу, а друга — містить дані банківської виписки про перерахування коштів за відвантажену продукцію. Представлена в такому розрізі оперативна інформація для сховища даних не є актуальною. Для аналізу та прийняття рішень потрібні дані про реалізацію продукції, тобто про ту частину продукції, яка була не лише відвантажена, але й оплачена, тобто за яку надійшли виписки про перерахування коштів на рахунок у банку. Таким чином, у сховищі даних повинні зберігатись не первинні оперативні дані, а результати їх певної обробки, які виконуються при вирішенні задачі «Автоматизація обліку реалізації готової продукції». Тобто використання методу реконструкції потребує глибоких знань предметної області та специфіки і особливостей функціонуючих OLTP-систем.

Крім того, суттєвим недоліком зазначеного підходу до проектування сховищ даних є те, що він орієнтується на існуючі джерела OLTP-систем і не враховує зовнішніх даних, які можуть виявитись досить суттєвими для бізнес-аналізу, який потрібно виконувати в даній предметній області.

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

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

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

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

Якийсь час назад OLAP-продукти підтримували або реляційне, або багатовимірне зберігання. Сьогодні, як правило, один і той же продукт забезпечує обидва ці види зберігання, а також третій вигляд - змішаний. Застосовуються наступні терміни:

MOLAP (Multidimensional OLAP) - і детальні дані, і агрегати зберігаються в багатовимірній БД. В цьому випадку виходить найбільша надмірність, оскільки багатовимірні дані повністю містять реляційні.

ROLAP (Relational OLAP) - детальні дані залишаються там, де вони "жили" спочатку - в реляційній БД; агрегати зберігаються в тій же БД в спеціально створених службових таблицях.

HOLAP (Hybrid OLAP) - детальні дані залишаються на місці (в реляційній БД), а агрегати зберігаються в багатовимірній БД.

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