Тема. Концепція побудови сховищ даних.

План
1. Характеристика трансакційних та аналітичних систем.
2. Поняття сховищ даних та передумови їх створення.
3. Основні характеристики сховищ даних.
4. Характеристика основних компонент сховища даних.
5. Архітектура сховищ даних.

1. Поняття сховищ даних.

2. Архітектура сховищ даних.
3. Інформаційні потоки в сховищі.
4. Інструменти та технології сховищ.
5. Проєктування сховищ.
 Характеристика трансакційних та аналітич них
систем
Інформаційні системи, орієнтовані на
оперативну об- робку даних, що зберігаються в базах
даних, належать до класу трансакційних систем.
Задачі, які вирішуються в цих системах, є задачами
класу OLTP (On-line Transactional Procеssing).
Трансакційні системи, або системи
операційної обробки даних (СОД),
орієнтовані на оперативну обробку даних, що
характеризують поточний стан об’єктів
предметної області.
Саме до цього класу належать традиційні облікові
та інші за- дачі, які обробляють первинну інформацію
і вирішуються пере- важно на основі методів прямого
розрахунку. Характерною озна- кою трансакційних
систем є те, що дані, які вони обробляють, постійно
поновлюються і, як правило, тривалий час ці дані не
зберігаються. Дані оперативних файлів БД переважно
зберіга- ються протягом одного місяця і після
підбиття підсумків за результатами роботи за місяць
вони вивантажуються з активної БД в архіви (це в
кращому випадку), а частіше знищуються. Ці системи
можна віднести до першого покоління інформаційних
систем, призначенням яких була автоматизація
рутинних операцій обробки даних.
Розвиток інформаційних систем засвідчив, що
автоматизація лише задач трансакційного класу є
недостатньою з погляду ефек- тивності управління.
Для прийняття обґрунтованих управлінсь- ких рішень
необхідно вирішення аналітичних задач. Враховуючи
технологічні особливості автоматизації аналітичних
задач, вони виокремлюються в клас систем, які дістали
назву аналітичних. Такими часто називають системами
підтримки прийняття рішень, бо їх основна мета —
допомогти управлінському персоналу ор- ганізації
ухвалити правильне і своєчасне рішення.
Аналітична система (АС) — це інформаційна
система, орієнтована лише на аналіз даних.
Зауважимо, що з позицій інформаційних процесів
аналітична система є вторинною щодо трансакційної
системи, оскільки всі дані, що використовуються для
аналізу, необхідно спочатку на- громадити і, за
можливістю, частково обробити, чим і займають- ся
різні трансакційні системи, і лише потім їх
проаналізувати.
Аналітичні задачі залежно від концепції аналізу
можна поділити на дві групи:
 задачі статичного аналізу;
 задачі оперативного аналізу.
Ці дві групи аналітичних задач суттєво
відрізняються між со- бою. До першої групи належать
регламентні аналітичні задачі, які вирішуються з
певною, заздалегідь відомою періодичністю. Ця група
задач характеризується тим, що вони реалізуються на
основі традиційної технології їх автоматизації. При
цій технології споча- тку формулюється технічне
завдання, яке передається програмісту на
програмування. Програміст виконує програмування і
тестуван- ня програми і лише після цього отримує
результат у вигляді рег- ламентованих, тобто чітко
визначених форм звітів. За такого під- ходу виникає
велика затримка в часі між моментом виникнення
потреби в аналізі та одержанням його результатів.
Дуже часто отриманий результат аналізу, який був
потрібний аналітику, запіз- нюється і рішення
 приймається без його врахування. Тому для
прийняття оперативних рішень такий вид аналізу не
придатний.
До другої групи належать нерегламентні аналітичні
задачі, які вирішуються при виникненні потреби в
бізнес-аналізі особи, що приймає рішення. Тобто
періодичність і представлення результа- тів вирішення
цих задач на може бути регламентована. Ці задачі
вирішуються за запитами, структура та види яких
можуть зміню- ватись залежно від бізнес-потреб.
Потреба в оперативному багатоаспектному бізнес
аналізі при- вела до виникнення нової технології
вирішення аналітичних за- дач, яка дістала назву
OLAP (On-Line Analytical Processing). Ця технологія
призначена забезпечувати аналітиків динамічним
багатовимірним аналізом консолідованих даних.
Вирішення аналітичних задач не може
обмежуватись лише да- ними трансакційних систем.
Для порівняльного аналізу та вияв- лення тенденцій
потрібно залучати великі обсяги зовнішніх даних з
різних статистичних збірників електронних та інших
джерел. Самі аналітичні запити складніші, ніж запити,
які формулюються в трансакційних системах. Так,
одним із запитів до OLTP-системи буде отримання
інформації про суму коштів на рахунка конкрет- ного
клієнта. В аналітичній системі запит може мати таке
формулювання: «Знайти середнє значення проміжку
часу між виставлен- ням рахунка та сплатою його
клієнтом у поточному і попередньо- му роках у
розрізі різних груп клієнтів». Виконати такий запит у
термінах мови SQL на основі традиційних баз даних
дуже складно. Для того, щоб реалізовувати
оперативним чином аналітичні запити, дані повинні
бути організовані відмінним від прийнятого в OLTP-
 системах способом. Це пов’язано з такими
факторами:
 по-перше, для реалізації аналітичних запитів
потрібна оброб- ка великих обсягів інформації. У БД
дані зберігаються в нормалі- зованому вигляді: чим
більша ступінь нормалізації, тим більше в реляційній
базі даних таблиць, тим повільніше виконуватиметься
аналіз, бо потрібно здійснити багато операцій
об’єднання таблиць;
 по-друге, виконання деяких аналітичних запитів,
пов’язаних з виявленням тенденцій і прогнозуванням,
потребує впорядкова- них даних. Реляційна модель не
передбачає певного порядку в записах таблиці.
Тому виконання аналітичних запитів на традиційній
базі даних нераціонально, а іноді неможливе. Зручним
способом зберігання даних для вирішення
оперативних аналітичних задач є різновид баз даних,
який носить назву сховище даних (Data Warehouse).
Доцільно провести певні розмежування та з’ясувати
взаємо- зв’язки OLAP-технологій і сховищ даних. Це
необхідно зробити тому, що іноді ці поняття
ототожнюються. Хоча ці дві концепції дуже часто
технологічно поєднуються, вони можуть бути жодним
чином не пов’язані між собою. Тобто сховища даних
як дже- рело даних можуть використовуватись не лише
для оперативних, а й для регламентних аналітичних
звітів. У той же час OLAP мо- же черпати дані для
оперативного аналізу не тільки зі сховищ даних, а
також з традиційних баз даних.
Поняття сховищ даних та передумови їх
створення
Концепція сховищ даних вперше було
сформульована у 1992 р. Необхідність розробки нової
концепції сховищ даних обу- мовлена такими
факторами:
 Системи підтримки прийняття рішень, що
ґрунтуються на формуванні аналітичних запитів,
почали конфліктувати з транс- акційними системами
оперативної обробки даних (OLTP- системами).
Одночасне вирішення оперативних та аналітичних
запитів на одній базі даних часто призводить до
нестачі ресурсів.
 Реалізація аналітичних звітів на основі
традиційних баз да- них, які містять оперативну
інформацію, займає дуже багато ча- су. Це пов’язано
з тим, що для аналітичних звітів переважно по- трібні
не первинні оперативні дані, а певним чином
узагальнені, тобто агреговані дані. Причому витрати
часу, необхідні на фор- мування аналітичних звітів,
невпинно зростають по мірі зростан- ня обсягів
оперативної інформації в базі даних. Це призводить
до затримок при реалізації аналітичних запитів.
 Дуже часто на підприємстві чи в організації
функціонує кі- лька OLTP-систем, кожна з яких має
свою окрему базу даних. Уних використовуються
різні структури даних, способи кодуван- ня, одиниці
вимірювання. Побудова зведеного аналітичного за-
питу на основі кількох баз даних є дуже складною
проблемою, яка спочатку потребує вирішення
проблеми узгодженості даних, що зберігаються в
різних базах даних.
 Для вирішення оперативних аналітичних задач
недостатньо інформації, що зберігається в базі даних.
Необхідні архівні дані, що містять результати роботи
за попередні календарні періоди. Крім того, дуже
часто виникає потреба в зовнішніх джерелах (дані
про клієнтів, конкурентів, політичні, соціологічні,
демографічні та ін.).
 Основні відмінності трансакційних систем від
аналітичних, що створили передумови для розробки
концепції сховищ даних, згруповані в табл. 9.1.
ПОРІВНЯЛЬНІ ХАРАКТЕРИСТИКИ ТРАНСАКЦІЙНИХ ТА АНАЛІТИЧНИХ СИСТЕМ
Ознаки Трансакційна система (ТС)
Облік, зберігання й оперативна
обробка первинних, деталізова-
Мета системи них даних, що характеризують
поточний стан об’єктів
предме- тної області (ПО)
Потрібні поточні оперативні
да- ні, що деталізовано
Джерела та види характери- зують стан об’єктів
даних ПО, як пра- вило, за останній
та кілька попередніх місяців
Оперативні БД можуть містити
семантично еквівалентну інфо-
рмацію, представлену в різних
форматах, яка не завжди може
Вигляд даних бути узгодженою між собою
(через використання різних
технологій і різних СКДБ)
Ознаки Трансакційна система (ТС)
Дані є динамічними, тобто
Частота оновлен- безперервно оновлюються і
ня дуже часто змінюються
Перелік запитів до трансакцій-
них систем уже відомий при її
проектуванні. Переважають
рег- ламентні запити, які
детерміно- вані в часі, тобто
вирішуються з певною
періодичністю і ма- ють
Характер запитів фіксований перелік вихід- них
до системи повідомлень. При вирі- шенні
цих задач переважають дуже
часті вибірки з БД даних
невеликими порціями. ТС в ос-
новному складаються із задач
прямого розрахунку
Таблиця 9.1
Аналітична система (АС)
Отримання і зберігання
узагаль- нених даних про ПО і
подання їх у вигляді, зручному
для біз- нес-аналізу та
підтримки при- йняття
стратегічних рішень
Крім детальних, потрібні уза-
гальнені дані за певні часові
ін- тервали, а також історичні
дані, накопичені за тривалий
період. Крім внутрішніх даних
потрі- бні зовнішні дані
Сховище даних повинно містити
узгоджену інформацію, що пред-
ставлена в однакових форматах
і максимально відповідає
опера- тивній БД. Тобто
сховища даних повинно
включати компоненту для
приведення до єдиного ви-
гляду інформації з різних дже-
рел
Закінчення табл. 9.1
Аналітична система (АС)
Дані є статичними, тобто вони
практично не змінюються, а
лише поповнюються новими
записами
При вирішенні аналітичних
задач переважають нерегламе-
нтні запити, які потребують
об- робки великих обсягів
інформа- ції. Тобто запити
потребують агрегованих даних
(сум, мініма- льних,
максимальних, середніх та
інших агрегатів даних). АС
повинна надавати аналітику
різноманітні інструменти для
обробки даних, з використан-
ням різних методик аналізу
(на- приклад, статистичні

Складання певного фіксованого
набору звітних форм, заздале-
гідь відомої структури. Пере-
важна кількість цих звітів ви-
Представлення магають первинної
результатів робо- деталізованої інформації
ти
Для оперативної БД, як прави-
ло, досить захисту на рівні
Захист таблиць
Мета даними в OLTP-системах
Наявність мета користуються переважно лише
даних адміністратори систем
методи, нейронні мережі,
генетичні ал- горитми, нечітка
логіка і т. п.)
Отримання великого числа рі-
зноманітних звітів на основі
агрегованих даних. Надання
аналітику можливості самому
визначати характер даних, що
використовуються, і форму
звітів. Виведення аналізу в
зручному для розуміння ви-
гляді (графічному, табличному
і т.ін.)
Захист аналітичних даних по-
требує більшої грануляції (за-
хист на рівні окремих значень
аналітичних показників)
Репозитарій мета даних — це
необхідна компонента, яка є
довідником про дані сховища
для користувачів системи
 Перелічені вище фактори створили передумови для
розробки різновиду баз даних, що дістала назву сховища
даних.
Сховище даних — це інтегрований
накопичувач даних, які збираються з різних
систем та джерел і використовуються для
бізнес-аналізу та прийняття обґрунтованих
стратегічних рішень.
Взаємозв’язок баз даних зі сховищами даних наведено на рис. 9.1.
Первинні
документи

OLTP-звіти
Бази
даних OLTP-системи
Вихідні
файли
Сховище
Архіви даних

Зовнішні OLAP-системи Аналітичні

джерела звіти

Рис. 9.1. Взаємозв’язок баз даних і сховищ

даних
Перш ніж завантажити дані в сховище,
необхідно виконувати функції попереднього їх
відбору, конвертації та очистки.
Основні характеристики сховищ даних
Сховище даних (Data Warehouse) — це
предметно орієнтована, інтегрована, прив’язана до
часу та незмінна сукупність даних, призначена для
підтримки прийняття рішень.
 Сховища даних характеризуються предметною
орієнтацією, інтегрованістю, підтримкою
хронології, незмінністю і мінімальною
надлишковістю. Ці основні особливості сховищ
даних були визна чені в 1992р. їх винахідником
Біллом Інмоном. Вони незалежно від реалізації
властиві всім сховищам даних і полягають у
такому: Предметна орієнтація. Дані в сховищі
даних організовані від- повідно до основних
напрямів діяльності підприємства чи фірми
(замовники, продажі, склад і т. п.). Це —
відмінність сховищ даних від організації
оперативної БД, в якій дані організуються відповід-
но до процесів (відвантаження товару, виписка
рахунків і т. п.). Предметна організація даних не
лише спрощує проведення аналізу, але й значно
прискорює виконання аналітичних розрахунків.
Тоб- то сховища орієнтовані на бізнес-поняття, а не
на бізнес-процеси.
Інтегрованість. Дані у сховище надходять з
різних джерел, де вони можуть мати різні імена,
формати, одиниці вимірювання і способи
кодування. Перш ніж завантажити дані до сховища,
вони перевіряються, певним чином відбираються,
приводяться до одно- го єдиного способу
кодування, виду та формату і в необхідній мірі
агрегуються (тобто обраховуються сумарні
показники). Зцього моменту вони представляються
користувачеві у вигляді єдиного інформаційного
простору, які набагато простіше аналізувати.
Якщо, наприклад, у чотирьох різних базах даних
код товару кодувався чотирма різними способами,
то в сховищі даних буде використана єдина
система кодування.
Підтримка хронології. Дані в сховищі даних
зберігаються у вигляді «історичних пластів»,
кожен з яких характеризує певний календарний
період. Це дозволяє проводити аналіз зміни показ-
ників у часі. В OLTP-системах істинність даних
гарантована тільки в момент читання, оскільки
вже в наступну мить вони мо- жуть змінитися
внаслідок чергової трансакції. Важливою відмін-
ністю сховищ від OLTP-систем є те, що дані в них
зберігають свою істинність у будь-який момент
процесу читання.
В OLTP-системах інформація часто
модифікується як резуль тат виконання яких-
небудь трансакцій. Часова інваріантність да- них у
сховищі даних досягається за рахунок введення
полів, що характеризують час (день, тиждень,
місяць) у ключі таблиць. УСД містяться начебто
моментальні знімки даних. Кожний еле- мент у
своєму ключі явно або непрямо зберігає часовий
пара- метр, наприклад день, місяць або рік.
Незмінність. Дані сховища даних, що
характеризують кожен
«історичний пласт», не можуть змінюватись. Це
теж є суттєвою відмінністю даних, що
зберігаються у сховищі даних, від оперативних
даних. Останні дані в базі даних постійно
змінюються. Зданими сховища даних можливі
лише операції їх первинного завантаження, пошуку
та читання.
 Якщо при створенні OLTP-систем розробники
повинні враховувати такі моменти, як відкоти
трансакцій після збою сервера, боротьба із
взаємним блокуванням процесів (deadlocks),
збереження цілісності даних, то для сховища
даних ці проблеми не так актуальні. Перед
розробниками стоять інші задачі, пов’язані,
наприклад, із забезпеченням високої швидкості
доступу до даних.
Мінімальна надлишковість. Незважаючи на те,
що інформація до сховищ даних завантажується з
БД OLTP-систем, це не при- зводить до
надлишковості даних. Мінімум надлишковості
даних забезпечується тим, що перш ніж
завантажувати дані до сховищ, вони фільтруються і
певним чином очищаються від тих даних, які не
потрібні і не можуть бути використаними в бізнес-
аналізі.
Характеристика основних компонент сховища
даних
Враховуючи те, що сховища даних є новою
технологію, яка розвивається, існують різні
підходи до викладення структури. Згідно з [25]
схема основних компонентів сховища даних вклю-
чає до свого складу такі компоненти (рис. 9.2).
Менеджер завантаження виконує функції
диспетчеризації щодо регулярності завантаження
нових даних до сховища даних згідно зі
встановленим регламентом. Оскільки джерелом
даних можуть бути різні OLTP-системи, функції
менеджера заванта- ження також полягають в
очищенні, конвертації та приведенні даних до
заданого виду їх представлення в СД.
Джерела даних
Дані Зовнішні
дані
OLTP-систем

Менеджер завантаження
Предметні Мета-
дані Менеджер дані
сховища даних

Детальні Репози-
дані тарій

Агреговані
дані
СКБД
Менеджер

Засоби Data Засоби доступу

Mining користувача
OLАP-засоби

Рис. 9.2.
Основні
компонент
и сховища
даних
 Менеджер сховища виконує операції аналізу та
управління даними. Це такі основні операції: аналіз
узгодженості та несуперечності даних; перетворення
та переміщення даних з тимчасово- го сховища в
основні таблиці СД; створення індексів; денормалі-
зація даних у разі її необхідності; агрегація
(узагальнення) даних; резервне копіювання та
архівування даних.
Детальні (оперативні) дані — ця складова містить
усі детальні дані, які визначені схемою сховища даних.
Це можуть бути як первинні дані найнижчого рівня
деталізації, так і узагальнені до певного рівня
деталізації.
Агреговані дані — ця компонента містить дані, які
попередньо оброблені менеджером сховища з метою їх
часткового чи глибокого узагальнення. У цій частині
зберігаються певним чином відсортовані та згруповані
дані, необхідні для виконання за- питів.
Ця частина сховища є тимчасовою і змінною,
оскільки вона постійно модифікується у відповідь на
зміни запитів. Необхід- ність цієї компоненти
пов’язана з підвищенням продуктивності виконання
запитів. Узагальнені дані поновлюються по мірі над-
ходження нових даних до системи. Частково
узагальнені дані — це результат певного узагальнення
та агрегації детальних даних. Глибоко узагальнені дані
отримуються на основі узагальнення част- ково
узагальнених даних.
Репозитарій метаданих — це інформація про дані,
що збері- гаються в СД.
Структура метаданих може відрізнятися залежно від
їх при- значення. Метадані використовуються для
таких основних цілей:
 Вибірка і завантаження даних. Метадані містять
інформацію про джерела даних, способи та
періодичність їх вибірки і заван- таження в СД.
Обслуговування сховища. Метадані
використовуються для ав- томатизації процедур
узагальнення даних.
Обслуговування запитів. Метадані
використовуються для ви- значення переліку таблиць
для виконання запитів.
Менеджер запитів — це складова сховища, яка
виконує опе- рації, пов’язані з управлінням запитів
користувачів. Ця компоне- нта реалізується, як
правило, на базі СКБД, що підтримує схови- ще
даних, а також сховища даних і програм власної
розробки.
Користувачі спілкуються і працюють зі сховищем
за допомо- гою спеціальних засобів. До них можуть
бути віднесені OLAP- інструменти, засоби, що
підтримують технологію Data Mining, та різні засоби
доступу кінцевого користувача: створення звітів і за-
питів; інструмент що належать до систем підтримки
прийняття рішень (Executive Information System, EIS).
При визначенні програмно-технологічної
архітектури схови- ща потрібно мати на увазі, що
система прийняття рішень, на які б візуальні засоби
вона не спиралася, повинна надавати користува- чеві
можливість деталізації інформації. Керівник
підприємства або фірми, отримавши інтегроване
представлення даних і висно- вки, зроблені на їх
основі, може зажадати детальніші дані, що уточнюють
джерело даних або причини висновків. З погляду
проектувальника сховищ даних це означає, що
необхідно забез- печити його взаємодію в деяких
випадках з БД OLTP-систем.
 Архітектура сховищ даних
Розрізняють такі види сховищ даних: корпоративні і
кіоски, або вітрини, даних.
Корпоративні сховища даних (enterprise data
warehouses) вміщують інтегровану інформацію,
зібрану з певної множини оперативних БД, яка
характеризує всю корпорацію і необхідна для
виконання консолідованого аналізу діяльності
корпорації в цілому. Такі сховища охоплюють усі
багаточисленні напрями ді- яльності корпорації і
використовуються для прийняття як такти- чних, так і
стратегічних рішень. Розробка корпоративного схо-
вища даних — дуже трудомісткий процес, який може
тривати від одного до кількох років, а обсяги сховища
можуть досягати від 50 Гбайт до кількох терабайт.
Кіоски, або вітрини, даних (data marts) — це певна
підмножи- на корпоративних даних, які
характеризують конкретний аспект діяльності
корпорації, наприклад роботу конкретного підрозділу.
Кіоск може вміщувати як агреговані, так і первинні
дані певної предметної області. Кіоск може
отримувати дані з корпоративно- го сховища даних
(залежний кіоск) чи бути незалежним і тоді джерелом
поповнення його даними будуть оперативні БД.
Розро- бка кіоску даних потребує значно менше часу і
в середньому за- ймає приблизно 3—4 місяці.
Корпоративні сховища даних і кіоски будуються за
подібними принципами і використовують практично
одинакові технології.
Останнім часом з’явилось поняття глобального
сховища даних, в якому сховище даних розглядається
як єдине джерело інтегро- ваних даних для всіх вітрин
даних.
 Успіх розробки та впровадження сховища даних
залежить від обґрунтованості вибору його архітектури.
Щодо концептуальної архітектури сховищ даних, то
згідно з [46] сховища даних залеж- но від підходів до
побудови їх архітектури поділяються на:
 віртуальне СД;
 СД на основі семантичної інтеграції предметних
областей;
 СД із системою управління запитами до предметних
областей;
 Монолітне сховище;
 СД на основі стандартного архіву даних.
Зупинимося детальніше на характеристиці кожної
архітектури.
Віртуальне сховище даних. Основою віртуального
сховища даних є репозитарій метаданих, який описує
місце розташування даних в оперативних системах,
структуру даних, методи агрегації та завантаження
даних, відомості про структуру бізнес-понять та інші
дані. Архітектурно-віртуальне сховище даних
складається з оперативних систем та системи
управління запитами, що зберігає свій репозиторій
метаданих (рис. 9.3).

У п р а в л ін н я
У с пад ко ван і запитам и і
с и с т е м и -д ж е р е л а К о р исту вач
р е п о з и т а р ій
даних м етаданих

Рис. 9.3. Архітектура віртуального сховища даних

Коли користувач запускає на виконання запит, то

засоби управління запитами, використовуючи
метадані, виконують по- шук та вибірку необхідних
даних з оперативних систем. Потім ці дані
об’єднуються необхідним чином і видаються
користувачеві. Тобто при виконанні запитів щоразу
дані об’єднуються з різних оперативних систем, тому
системи, побудовані за цими принци- пами,
характеризуються низькою продуктивність виконання
за- питів. Інший недолік такої архітектури —
можливість отримання різних результатів на одні й ті
ж запити, виконані у різний час, оскільки дані
оперативних систем постійно змінюються і не збе-
рігають історичних даних. Ще одна суттєва перепона,
яка стоїть на шляху побудови такої архітектури, — це
відсутність єдиної структури полів, кодів і ключів.
Тому для організацій з розгалу- женою
організаційною структурою та наявністю великої
кількос- ті інформаційних систем, кожна з яких
працює зі своєю базою даних, такий підхід до
архітектури сховища даних не може бути
прийнятним, оскільки кожного разу для виконання
запитів потріб- но буде об’єднувати дані з різних
систем замість того, щоб це зробити один раз при
створенні сховища даних.
Переваги цієї архітектури полягають у тому, що
максимально використовується існуюче апаратне
забезпечення і основне нава- нтаження по виконанню
запитів беруть на себе системи-джерела, а система
управління запитами лише управляє результатом та
на- дає його користувачеві. Така архітектура побудови
сховища даних може бути рекомендована для
організацій, інформаційні системи-джерела якої
побудовані з урахуванням системного підходу. Тобто
вхідні дані для виконання запитів характеризуються
високою якістю, наявністю спільних ключів і систем
кла сифікації та кодування. Крім того, інформаційні
системи-джерела мають засоби обмежень ресурсів,
які виділяються для виконання
запитів, що надходять з віртуального сховища, щоб
уникнути ефекту «затоплення» запитами сховища.
Архітектура сховища на основі семантичної
інтеграції пред- метних областей. Сховище,
побудоване за цією архітектурою, поділено на певні
розділи, кожен з яких характеризує окрему
предметну область, але проектуються вони за
єдиними правила- ми, що гарантує легкість їх
об’єднання. Тобто спочатку проекту- ється єдина
корпоративна модель сховища, яка забезпечує іден-
тичність структур полів, кодів і первинних ключів. Цю
архітектуру схематично можна відобразити таким
чином (рис.9.4):

Успадковані
системи-
джерела даних

Вибірка,
перетворенн
я та

Предметна Предметна Предметна

область 1 область 2 область 3

(кіоск 1) (кіоск 2) (кіоск 3)

Користувач

Рис. 9.4. Архітектура сховища на основі семантичної інтеграції

предметних областей
Переваги цієї архітектури полягають у фізичному
розподілі сховища даних за предметними областями та
 простоті проекту- вання. Після визначення процедур
вибірки даних і зв’язків між окремими предметними
областями можна приступати до розроб- ки сховища для
певної предметної області. Тобто сховище для окремої
предметної області можна розробляти незалежно від
інших предметних областей.
Для запобігання того, щоб для кожної предметної
області робити окремі вибірки даних, програмні засоби
будуються таким чином, щоб при вибірці даних
виконувалася семантична інтегра- ція, необхідна для
побудови сховищ даних усіх предметних областей.
Вибрані дані розміщуються в проміжній області даних, і
зберігаються рівно стільки часу, скільки необхідно для
заповнення сховищ предметних областей. Потім вони
архівуються і знищуються.
Проблемним є питання виконання запитів, що
стосуються кількох предметних областей. Тобто серйозним
недоліком цих сис- тем є відсутність системи управління
запитами, внаслідок чого на виконання запитів, що
стосуються різних предметних областей, витрачається
значний час, оскільки необхідно, щоб СКБД об’єднала дані
з різних ПО в одну загальну таблицю для реаліза- ції таких
запитів. Ця архітектура придатна: для організацій, що
мають на меті послідовну розробку сховищ даних для
кількох предметних областей, або кількох вітрин даних;
для корпоратив- ного управління на основі його
децентралізації при централізова- ному підході до обробки
даних таких організацій, які не мають потреби в отриманні
інтегрованих рішень на основі інформації кількох
предметних областей.
Архітектура із системою управління запитами до
предметних областей. Ця архітектура, на відміну від
попередньої, доповнюється блоком управління запитами
(схематично відображена на рис. 9.5).
Наявність блоку управління запитами дозволяє
користувачеві глибоко не занурюватись у деталі побудови
структур даних кож- ної предметної області. За допомогою
блоку «Управління запи- тами» спрощується вирішення
проблеми семантичної інтеграції областей, але
залишається недолік, що насамперед виявляється у
значного часі виконання запитів до різних предметних
областей. Тому для організацій, які характеризуються дуже
великими обся- гами інформації, така архітектура сховища
даних є недоцільною, оскільки час реалізації запитів при
збільшенні обсягів сховища да- них буде весь час зростати.
Ця архітектура вписується в корпора- тивний стиль
управління організацій з централізованою обробкою даних
і децентралізованим управлінням, які потребують
створення кількох вітрин даних і мають потребу в
отриманні інтегрованих рішень на основі інформації
кількох предметних областей.
 Успадкування
Успадковані
системи-
системи-джерела
джерела даних

Вибірка, пертворення
та інтеграція

Предметна Предметна Предметна

область 1 область 2 область 3
(кіоск 1) (кіоск 2) (кіоск 3)

Управління запитами

Користувач

Рис. 9.5. Архітектура із системою управління запитами до

предметних областей
Монолітне сховище. Монолітне сховище містить не дані
всіх предметних областей, а метадані. Тобто це репозиторій
усіх досту- пних на даний момент оперативних даних, які
представлені на най- вищому рівні деталізації і нормалізації.
Запити не виконуються над монолітним сховищем. Дані із
монолітного сховища надходять у допоміжне сховище, яке є
проміжним сховищем даних (intermediate data store), а потім
передаються у сховища даних предметної області, яке
називається робочим сховищем (business data warehouse).
Архітектура монолітного сховища наведена на рис. 9.6.
Перевагою такої архітектури сховища даних є його гнучкість
для використання спеціалістами, а недоліками — занадто
велика кількість рівнів і значна надлишковість, що ускладнює
супрово- дження. Ця архітектура придатна для організацій з
централізованою командно-адміністративною системою
управління, які можуть ви- ділити значні кошти та задіяти
велику кількість персоналу для розробки та впровадження
технології на основі сховища даних.
 Успадковані систе-
ми-джерела даних

Вибірка і перетворення
Вибірка і
перетворенн

Монолітне сховище
Монолітне
сховище
Проміжне Проміжне
сховище сховище

Предметна Предметна
область 1 Користувач область 2
(кіоск 1) (кіоск 2)
Рис. 9.6. Архітектура монолітного сховища даних

Стандартний архів даних. Сховище на основі стандартного

архіву відображено на рис. 9.7.

Успадковані
Успадкування
системи-
системи-
джерела даних
джерела даних

Вибірка,
пертворенн
я та

Предметна Предметна Предметна

область 1 область 2 область 3
(кіоск 1) (кіоск 2) (кіоск 3)

Користувач

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

 При використанні цієї архітектури процес семантичної інтег- рації і
проміжне сховище заміняються стандартним архівом. Стан- дартний
архів — це стаціонарне інтегроване сховище, що вміщує інформацію
для всіх СППР, і яке можна використовувати для за- повнення сховищ
окремих предметних областей і вітрин даних. Недоліком цього типу
архітектури є високі витрати на пам’ять та підвищені вимоги до
супроводження. Великі витрати пам’яті пов’язані з тим, що дані у
стандартному архіві повинні зберіга- тись в такому вигляді, щоб легко
забезпечувати обробку опера- тивних деталізованих запитів до сховища
даних.
Ще одним суттєвим недоліком архітектури цього типу є відсутність
інтеграції окремих предметних областей. Тому включення додаткового
блоку управління запитами (рис. 9.8) підвищує зручність використання
сховищ даних при виконанні інтегрованих запитів, для реалізації яких
потрібні дані з кількох предметних областей.

Успадковані
системи-
Успадкування
джерела даних
системи-
джерела даних

Вибірка,
пертворенн
я та

Предметна Предметна Предметна

область 1 область 2 область 3
(кіоск 1) (кіоск 2) (кіоск 3)

Управління
запитами

Користувач

Рис. 9.8. Архітектура сховища на основі стандартного архіву даних з

блоком управління запитами
 Архітектури монолітного сховища і стандартний архів
даних є найбільш придатними для побудови
корпоративних сховищ да- них, оскільки можуть
задовольнити потреби в інформації всіх користувачів-
аналітиків та вищий менеджмент організації.
Найдоцільніше користуватись архітектурою на основі
стандартного архіву даних. Ця архітектура
характеризується масштабованістю, а заповнення сховищ
окремих предметних областей виконується зі
стандартного архіву, дані в якому перебувають уже в
очище- ному та узгодженому стані, що забезпечує якість
інформації та ефективність рішень, які приймаються на
основі її аналізу.
Питання для самоперевірки
1. Охарактеризуйте передумови створення концепції схо вищ
даних.
2. Охарактеризуйте відмінності між аналітичними і транс
акційними системами обробки даних.
3. Дайте визначення сховища даних і наведіть основні його
відмінності від бази даних.
4. Дайте визначення корпоративного сховища даних та віт рини
(кіоску) даних.
5. Перелічіть види побудови архітектури сховищ даних.
6. Охарактеризуйте архітектуру сховища даних на основі
семантичної інтеграції предметних областей.
7. Охарактеризуйте архітектуру сховища даних з системою
управління запитами до предметних областей.
8. Охарактеризуйте архітектуру монолітного сховища даних.
9. Охарактеризуйте архітектуру сховища даних на основі
стандартного архіву даних.
10. Охарактеризуйте основні компоненти сховища даних.