Бази даних та сховища даних

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

Область подання просторово структурована, при цьому вона може бути централізованою або розподіленою. Просторова модель сховища даних містить ту ж атомарну інформацію, що й нормалізована модель, але інформація структурована по-іншому, щоб полегшити її використання й виконання запитів. Ця модель включає як атомарні дані, так і узагальнювальну інформацію (аґреґати у зв'язаних таблицях або багатомірних кубах) відповідно до вимог продуктивності або просторового розподілу даних. Запити в процесі виконання звертаються до усе нижчого рівня деталізації без додаткового перепрограмування з боку користувачів або розроблювачів застосування.

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

Гібридна архітектура, яка поєднує особливості реляційної та багатовимірної моделей, запропонована Дугласом Хекні. Іншою назвою моделі є Узгоджувана вітрина даних. За такої архітектури передбачається подвійне проектування схеми сховища даних – розроблення нормалізованого центрального (корпоративного сховища) та багатовимірних (побудованих за архітектурою шини) вітрин даних. Корпоративне нормалізоване сховище дозволяє коректно зберігати дані, а ненормалізовані вітрини – швидко виконувати запити користувачів.

Зведення даних –  предметно орієнтована, історична  і унікально зв'язана множина  нормалізованих таблиць, які підтримують  одну або більше функціональних предметних областей. Це – гібридний підхід, що поєднує кращі особливості 3-ої нормальної форми (3НФ) і схеми «зірка». Модель гнучка, масштабується, послідовна і пристосована до потреб різних предметних областей. Вона відповідає потребам сховища даних і відкидає потребу у використанні вітрин даних та, на відміну від гібридного підходу Хекні, не вимагає подвійної роботи для надбудови архітектури шина над архітектурою корпоративної фабрики.

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

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

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

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

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

         Операційне сховище даних (ОСД) – це предметно-орієнтований, інтеґрований, змінюваний набір консолідованих даних, який містить поточну (не історичну) деталізовану інформацію.

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

Інша відмінність полягає у тому, що операційне сховище містить тільки дані, актуальні на певний момент часу, тоді як в сховищі містяться як поточні, так і історичні дані. При цьому  актуальність даних в сховищі значно нижча, ніж в операційному сховищі. Як правило, в сховищі містяться дані, завантажені протягом останніх 24 годин, тоді як актуальність даних в ОСД може вимірюватися секундами. Ще однією відмінністю ОСД від сховища є те, що в ньому містяться тільки детальні дані, тоді як сховище містить як детальні, так і аґреґовані дані.

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

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

1. Інструменти для  створення насосів даних (data pump), тобто модулів, що функціонують за середовищем джерел даних і поставляють у сховище ті зміни, які істотні з точки зору сховища; при цьому дані мають транслюватися у відповідності з глобальною моделлю і схемою сховища.

Методи "чистки даних" (data scrubbing), які забезпечують узгодження даних, видалення елементів, що відповідають різним уявленням одного й того ж об'єкта (наприклад "Sally Tones" і "SA Tones"), а також видалення неправдоподібних значень.

4. Види сховищ даних

При використанні СППР можуть застосовуватись 2 види сховищ даних:

Фізичне СД

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

Така модель безсумнівно  приводить до дублювання інформації в ОДД та в СД. Проте така надлишковість  не перевищує 1%. Це пояснюється такими причинами:

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

Віртуальне  СД

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

• мінімізація обсягу пам'яті, який займають дані на носії інформації;
• робота з поточними, деталізованими даними.

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

Головним же недоліком  віртуального сховища даних вважається практична неможливість отримання даних за довгий період часу. При відсутності фізичного сховища доступні тільки ті дані, які на момент запиту містяться в ОДД. Основне призначення OLTP-систем — оперативна обробка поточних даних, тому вони не орієнтовані на зберігання даних за тривалий період часу. По мірі застарівання дані вивантажуються в архів та видаляються з оперативної БД.

Інша типологія 

Корпоративні  сховища даних

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

Кіоски даних

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

Основними постачальниками  програмного забезпечення сховищ даних  є компанії Arbor, Hewlett-Packard, IBM, Informix, Microsoft, Oracle, Platinum Technology, SAS Institute, Software AG,Sybase та ін. Усі ці фірми мають сторінки в Internet, на яких наводяться детальні відомості про їх продукти та послуги.

Проблеми створення  СД

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

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

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