| Предметна орієнтованість | Всі дані про деяку сутність (об'єкті, процесі тощо) із деякої предметної області збираються із безлічі різних джерел, очищаються, узгоджуються, доповнюються, агрегуються і представляються в єдиній, зручній для їх використання в бізнес-аналізі формі. У сховищі дані організовані (впорядковані) за предметами (входами). Наприклад, клієнти, постачальники, товари, регіони тощо |
| Інтегрованість | Всі дані про різні об'єкти чи процеси взаємноузгоджені за кодуванням, форматами, одиницями вимірювання тощо (наприклад, позначення статі завжди буде «ч» та «ж» і ніяк інакше, дати зберігатимуться в одному форматі, значення всіх однотипних величин представлені в тих самих одиницях вимірювання) і зберігаються в єдиному загальнокорпоративному сховищі у формі, зручній для швидкої вибірки і сортування |
| Підтримка хронології | Дані хронологічно структуровані за часом, тобто являють собою сукупність часових зрізів («моментальних копій») і відбивають історію за період часу, достатній для виконання задач аналізу, прогнозування і підготовки прийняття рішення |
| Незмінність | Вихідні (історичні) дані, після того, як вони були узгоджені, верифіковані і внесені до загальнокорпоративного сховища, залишаються незмінними і використовуються виключно в режимі читання |
Сховище даних виконує багато функцій, та його основне призначення - надання точних даних і інформації в найкоротші терміни і з мінімумом витрат. Типове сховище даних зазвичай відрізняється від традиційної бази даних. По-перше, традиційні БД призначені для того, щоб допомогти користувачам виконувати повсякденну роботу, тоді як сховища даних призначені для прийняття рішень. Наприклад, продаж товару і виписування рахунку здійснюється з використанням бази даних, призначеної для опрацювання транзакцій (транзакційна БД) а аналіз динаміки продажів за декілька років, що дозволяє спланувати роботу з постачальниками, — за допомогою сховища даних. По-друге, традиційні бази даних характеризуються постійними змінами у процесі роботи користувачів, а сховище даних відносно стабільне: дані у ньому зазвичай оновлюються за розкладом (наприклад, щотижня, щодня або щогодини — залежно від потреб). В ідеалі процес поповнення (або як далі ми будемо називати завантаження) є просто додаванням нових даних за певний період часу без зміни попередньої інформації, що вже міститься в сховищі. І, по-третє, традиційні бази даних найчастіше є джерелом даних, що потрапляють у сховище. Крім того, сховище може поповнюватися за рахунок зовнішніх джерел, наприклад статистичних звітів. У разі відмінності за форматом застосовують додаткові процедури трансформування та завантаження даних (так звані процедури Extract, Transform, Load).
Як і БД, сховища даних можуть будуватись на основі певної системи управління базами даних. СУБД забезпечує загальний репозиторій для зберігання і опрацювання структурованих даних, підтримує набір взаємозв'язаних послуг і дає розробникам змогу зосередитись на специфічних проблемах їх застосувань, а не на завданнях, які виникають при потребі в узгодженому й ефективному керуванні великими обсягами даних. Проте СУБД вимагають, щоб всі дані знаходилися під єдиним адміністративним керуванням і відповідали єдиній схемі. У відповідь на задоволення цих обмежень СУБД можуть забезпечити розвинені засоби маніпулювання даними та опрацювання запитів зі зрозумілою і строгою семантикою, а також строгі транзакційні ґарантії оновлень, паралельного доступу і довготривалого зберігання.
Поняття сховище даних в первинному розумінні було засноване на понятті розподіленої вітрини даних (Distributed Data Mart – DDM. Вітрина даних (ВД) — зріз сховища даних, масив тематичної, вузьконапрямленої інформації з обмеженою кількістю входів, орієнтований на відносно вузький сегмент користувачів, наприклад, на користувачів однієї робочої групи або регіонального департаменту і може розглядатися як окрема БД.
Середовище сховища було призначене лише для читання і складалася з повністю очищених та інтегрованих детальних і агрегованих даних; крім того, в репозиторії зберігалася обширна і детальна історія даних на рівні транзакцій. З погляду архітектурного рішення таке сховище даних реалізує свої функції через підмножину залежних вітрин даних і будується за дворівневою архітектурою. Побудова повноцінного корпоративного сховища даних зазвичай виконується в трирівневій архітектурі (рис. 4.11).
Рис. 4.11. Схема організації даних в сховищі
На першому рівні розташовані різноманітні джерела даних – дані кінцевих користувачів, які поступають через мережу; внутрішні системи реєстрації даних та системи оперативної обробки транзакцій, які фіксують відомості про щоденну ділову активність, довідкові системи, зовнішні джерела (дані інформаційних агентств, макроекономічні показники). Другий рівень містить центральне сховище, куди стікається інформація від всіх джерел з першого рівня, і, можливо, оперативне сховище даних (сховище поточної інформації, що не містить історичних даних і виконує дві основні функції - джерела аналітичної інформації для оперативного керування та підготовки даних для наступного завантаження в центральне сховище). Доступ до даних здійснюється через ODBC (Open Database Connectivity) чи драйвер OLE, шляхом здійснення запитів до довільних джерел даних та самого сховища чи окремих вітрин, через Інтернет чи корпоративну мережу.
Збереження та використання даних у сховищі передбачає дії з його побудови, керування та експлуатації. При побудові сховища обирається його архітектура; системи оперативної обробки транзакцій розташовуються на сервері сховища даних, у центральному архіві, а дані з них обробляються – очищаються, переформатовуються, додаються, індексуються тощо. Керування сховищем передбачає перевірку достовірності даних, управління даними та метаданими, усім програмним та апаратним забезпеченням, персоналом та процедурами, тобто системою сховища даних загалом. Експлуатація сховища полягає у його використанні для підтримки прийняття рішень. Технологія сховищ даних дає користувачу доступ до даних, надає можливість здійснювати регламентовані та нерегламентовані запити, оперативну ананітину обробку (On-Line Analytical Processig, OLAP), інтелектуальний аналіз (Data Mining) та обчислення даних, візуалізувати їх та обмінюватися ними по мережі.
Класична архітектура сховищ даних не передбачала оперативних сховищ і мала наступні переваги:
· спільна семантика;
· централізоване, кероване середовище;
· узгоджений набір процесів видобування даних і бізнес-логіки використання;
· несуперечність інформації, яка зберігається;
· легко створювані за шаблонами і легко наповнювані вітрини даних;
· єдиний репозиторій метаданих;
· різноманіття механізмів обробки і представлення даних.
Недоліками є великі витрати з реалізації, висока ресурсоємність в масштабі всього підприємства, потреба в складних сервісних системах, ризикований сценарій розвитку, коли всі дані і метадані знаходяться в одному репозиторії і в несприятливому випадку можуть бути втрачені. Крім того, в процесі фільтрації, агрегації і рафінуванні "сирих" даних для такого сховища зазвичай втрачається дуже багато інформації, яка може бути надзвичайно корисною при бізнес-аналізі. У зв'язку з цим виникло розуміння того, що сховище, окрім механізмів розміщення і видобування даних, репозиторія і вітрин, повинне мати відповідний простір для організації "сирих" даних і їх багатовимірного аналізу в режимі реального часу.
Оперативне сховище даних (ОСД) – це предметно-орієнтований, інтеґрований, змінюваний набір консолідованих даних, який містить лише поточну (не історичну) деталізовану інформацію. На відміну від централізованого сховища, ОСД містить дані, що змінюються, тоді як в централізованому сховищі дані після завантаження не змінюються. Окрім того, ОСД містить тільки дані, актуальні на певний момент час у, тоді як в сховищі містяться як поточні, так і історичні дані. При цьому актуальність даних в сховищі значно нижча, ніж в ОСД. Як правило, в сховищі містяться дані, завантажені протягом останніх 24 годин, тоді як актуальність даних в ОСД може вимірюватися секундами. Ще однією відмінністю ОСД є те, що в ньому містяться тільки детальні дані, тоді як сховище містить як детальні, так і аґреґовані дані
Загалом сучасне сховище даних має такі особливості проектування та побудови стосовно БД:
· отримання інформації з різних джерел даних (у тому числі і з реляційних баз даних) у деталізованому та аґреґованому вигляді (зберігаються результати застосування функцій агрегації – суми, середнього значення, максимуму, мінімуму тощо);
· багатовимірне подання інформації – ігноруються деякі вимоги нормалізації (дотримують максимум 3-ої нормальної форми), що значно підвищує швидкість опрацювання інформації, оскільки зменшує кількість операцій з’єднання;
· наявність метаданих для опису джерел метаданих та структури самого сховища даних – у базах даних також використовують словники для опису структур даних, а у сховищах даних метадані (словники, дані про дані) повинні будуватися за класифікаційною схемою Захмана. За цією схемою описують об'єкти (що?), суб'єкти (хто?), місцезнаходження (де?), час (коли?), фактори впливу, чинники (чому?), способи (як?);
· наявність пакетного завантаження даних в сховище даних та вивантаження даних;
· наявність процедур аналізу даних та отримання нових даних;
· орієнтованість даних на аналітичне, а не на статичне опрацювання.
Сховища даних краще пристосовані до зберігання та аналітичного опрацювання великих обсягів даних і, в основному, є інтеграцією реляційної та багатовимірної моделей. Найрозповсюдженішими сьогодні є такі архітектури побудови сховищ даних: корпоративна інформаційна фабрика Білла Інмона, шина Ральфа Кімбола, зведення даних корпорації TDAN [96]. Вони мають розвинені засоби інтеґрації даних з різних джерел та дозволяють працювати як з деталізованою, так і аґреґованою інформацією.
Концепція корпоративної інформаційної фабрики, КІФ (Corporate Information Factory, CIF), розроблена В.Інмоном, орієнтована на збереження реляційних даних в сховищі даних і передбачає, що дані повинні перебувати на низькому рівні деталізації і в третій нормальній формі. Білл Інмон підтримує повторний або спіральний підхід до розвитку великого сховища даних. За цим підходом розвиток сховища відбувається ітераційно, тобто у разі виникнення потреби додається одна таблиця за один раз, що забезпечує лише незначну зміну схеми даних. Тому такий підхід до проектування сховища ще називають спіральним підходом.
У сховищах даних з архітектурою шини Ральфа Кімбола, які ще називають просторовими сховищами, первинні дані перетворюються в інформацію, придатну для використання, на етапі підготовки даних. При цьому обов'язково приймаються до уваги вимоги до швидкості опрацювання інформації і якості даних. Як і в моделі В.Інмона, підготовка даних починається зі скоординованого добування даних із джерел. Ряд операцій здійснюються централізовано, наприклад, підтримка і зберігання загальних довідкових даних, інші дії можуть бути розподіленими. Область подання просторово структурована, при цьому вона може бути централізованою або розподіленою. Просторова модель сховища даних містить ту ж атомарну інформацію, що й нормалізована модель, але інформація структурована по-іншому, щоб полегшити її використання й виконання запитів. Ця модель включає як атомарні дані, так і узагальнювальну інформацію (аґреґати у зв'язаних таблицях або багатомірних кубах) відповідно до вимог продуктивності або просторового розподілу даних. Запити в процесі виконання звертаються до усе нижчого рівня деталізації без додаткового перепрограмування з боку користувачів або розроблювачів застосування.
Просторові моделі будуються для обслуговування бізнес-процесів (які, у свою чергу, пов'язані з бізнес-показниками або бізнес-подіями), а не бізнес-відділів, як КІФ. Наприклад, дані про замовлення, які повинні бути доступні для загалькорпоративного використання, вносяться в просторове сховище даних тільки один раз, на відміну від КІФ-підходу, у якому їх довелося б тричі копіювати у вітрини даних відділів маркетинґу, продажів і фінансів. Після того, як у сховищі появляється інформація про основні бізнес-процеси, консолідовані просторові моделі можуть видавати їхні перехресні характеристики. Матриця корпоративного сховища даних з архітектурою шини виявляє й підсилює зв'язок між показниками бізнес-процесів (фактами) і описовими атрибутами (вимірами).
Гібридна архітектура (узгоджувана вітрина даних), яка поєднує особливості реляційної та багатовимірної моделей, запропонована Дугласом Хекні. За такої архітектури передбачається подвійне проектування схеми сховища даних – розроблення нормалізованого центрального (корпоративного сховища) та багатовимірних (побудованих за архітектурою шини) вітрин даних. Корпоративне нормалізоване сховище дозволяє коректно зберігати дані, а ненормалізовані вітрини – швидко виконувати запити користувачів.
Зведення даних – предметно орієнтована, історична і унікально зв'язана множина нормалізованих таблиць, які підтримують одну або більше функціональних предметних областей. Це – гібридний підхід, що поєднує кращі особливості 3-ої нормальної форми (3НФ) і схеми «зірка». Модель гнучка, масштабується, послідовна і пристосована до потреб
різних предметних областей. Вона відповідає потребам сховища даних і відкидає потребу у використанні вітрин даних, і, як наслідок, залучення для їх проектування окремого типу архітектури – шини Кімбола..
Зведення даних може керувати масивними наборами ґранульованих даних в меншому, більш нормалізованому фізичному просторі, наприклад 3НФ і схемі «зірка». Базується на математичних принципах, які підтримують нормалізовані моделі даних. Внутрішня частина моделі зведення даних – близькі структури, які відповідають традиційним визначення схеми «зірка» і 3НФ, що включають виміри, зв’язки багато-до багатьох і стандартні табличні структури. Відмінності полягають в подані зв’язків, структуризації поля і ґранульованому,
пов’язаному з часом, зберіганні даних.
Зростання вимог до різноманітності джерел інформації та форматів даних поряд зі зростанням доступності до цих даних за допомогою всесвітньої мережі призвели до розвитку технології зберігання інформації від баз і сховищ до просторів даних. І бази, і сховища даних дають змогу опрацьовувати деталізовані та інтегровані дані, що побудовані на основі наперед допустимих моделей даних. У випадку роботи у всесвітній мережі з величезною кількістю ресурсів неможливо визначити, які саме моделі даних використовуватимуться. Тому виключно за допомогою баз даних та сховищ даних не можна організувати ефективної взаємодії між усіма об'єктами у цих предметних областях. Перші публікації щодо опрацюванні різних джерел даних та використанні цих даних в єдиній предметній області, які можна вважати початком розробки концепції просторів даних [86], з’явилися у 2005 р.
Простір даних – це множина баз даних, сховищ даних, локальних сховищ та індексів, статичних Web-сторінок, графічних матеріалів, засобів інтеґрації, пошуку та опрацювання інформації [35; 81, с 59; 117]. Як ключова задача робіт в області керування даними використовується платформа підтримки просторів даних (DataSpace Support Platforms, DSSP). DSSP забезпечує набір взаємозв'язаних послуг і ґарантує розробникам можливість
концентруватися на специфічних проблемах їх додатків, а не на завданнях, що повторюються, виникають при потребі узгодженої й ефективної роботи з взаємозв'язаними, але роздільно керованими даними. На відміну від СКБД, в ядрі DSSP необхідна підтримка декількох моделей даних, щоб природним чином підтримувалося якомога більше типів учасників.
Однією з основних служб простору даних є каталогізація елементів даних учасників. Каталог – це реєстр ресурсів даних, що містить найбільш базову інформацію про кожний з них: джерело, ім'я, місцеположення в джерелі, розмір, дата створення і власник і т.д. Каталог є інфраструктурою для більшості інших сервісів простору даних, але він також може підтримувати базовий, призначений для користувача, інтерфейс проглядання простору даних. Він не тільки містить описову інформацію (тобто виконує роль метаданих), але й зберігає для кожного учасника схему джерела, статистичні дані, швидкість зміни, точність, можливості відповідей на запити, інформацію про власника і дані, про політику доступу і підтримку конфіденційності. Оскільки джерела простору даних фізично не переносять у нього інформацію та можуть обмінюватись між собою інформацією, то у каталозі необхідно зберігати дані і про зв’язки між джерелами. Поверх каталога розташоване середовище управління моделями, яке дозволяє створювати нові зв'язки і маніпулювати існуючими зв'язками (наприклад, об'єднувати або інвертувати відображення, зливати схеми і створювати єдині представлення декількох джерел). Чим більше моделей здатне «розрізнити» середовище управління, тим точнішою буде інформація в каталозі і тим ефективніше можна буде проводити процедури інтеграції, пошуку та опрацювання даних у просторі даних.
Засоби опрацювання даних DSSP підтримують наступні функції:
· видобування даних (Data mining) – асоціативні правила, дерева рішень, генетичні алгоритми тощо;
· оперативний аналіз даних (Analytical Processing, OLAP) – реляційний OLAP (Relational OLAP,ROLAP), багатовимірний OLAP (Multidimensional OLAP,MOLAP), гібридний OLAP (Hybrid OLAP, HOLAP), динамічний OLAP (Dynamic OLAP – DOLAP);
· природномовний пошук– побудова нечітких запитів, запитів у вигляді природних питань, запитів до метаданих;
· підбір контенту на основі аналізу характеристик користувача,
· миттєвий аналіз даних (наприклад, визначення причин підвищення тиску у котлах за значеннями давачів приладів та пропонування методів усунення неполадок).
У просторах даних повинні підтримуватися всі без виключення формати даних; підтримуватися структуровані, текстові, просторові, темпоральні, мультимедійні, процедурні дані; тригери; потоки і черги даних, як рівноправні компоненти; здійснюватися інтеграція тексту, даних, коду і потоків. Простори даних повинні забезпечувати вбудовану підтримку неточних даних через можливість задання неточних запитів, і процесор запитів повинен відноситися до цього як до додаткового джерела неповноти і неточності. Відповіді на запити повинні залежати від профілю користувача. Релевантність відповіді теж повинна залежати від користувача і від контексту. У разі суперечливої інформації з різних джерел чи недоступності частини з них DSSP здатні пропонувати найкращу (за заданими критеріями) відповідь з доступних відповідей на запит.
Питання для самоперевірки
1. Які вимоги до організації збереження інформації висувають сучасні інформаційні системи?
2. У чому специфіка концепції баз даних? Що таке база даних і у чому її переваги стосовно файлової системи?
3. Як забезпечуються самодокументованість і інтегрованість записів бази даних?
4. Чим забезпечується логічна зв'язність даних у базах даних?
5. Якщо розглядати базу даних як модель, то що виступатиме у ролі оригіналу цієї моделі?
6. Які основні типи даних використовують у базах даних?
7. Чим відрізняються прості і структуровані дані?
8. Що таке модель даних? Які її основні складові?
9. Які основні різновиди моделей даних та у чому мета їх побудови?
10. Які основні інформаційні одиниці ієрархічної моделі даних? Які операції та який тип цілісності підтримуються?
11. У чому відмінність мережевої моделі даних від ієрархічної?
12. З чого складаються структурна, маніпуляціна та цілісна частина реляційної моделі даних?
13. Що таке тип даних, атрибут і домен у реляційній моделі? Чи є порівняльнми дані одного типу, але з різних доменів?
14. Як представляють відношення у реляційних базах даних?
15. Що таке первинний ключ відношення? Скільки первинних ключів млже мати відношення і які обмеження накладаються на первинні ключі?
16. Як забезпечуються цілісність сутностей та посилань у реляційній моделі?
17. Які основні відмінності постреляційної та багатовимірної моделей даних? Де вони застосовуються?
18. На чому базується об’єктна-орієнтована модель даних? Як у ній забезпечується цілісність?
19. Що таке система управління даними (СУБД) та які її основні функції?
20. Як реалізується надійність збереження даних у базі за допомого протоколу WAL?
21. З яких основних компонентів складається СУБД? Які функції цих компонентів?
22. Чи передбачає проектування бази даних проектування СУБД?
23. Що таке модель бази даних? Чим вона відрізняється від моделі даних?
24. Які рівні представлення предметної області виділяють у схемі представлень ANSI/SPARC?
25. Які основні етапи проходить проектування бази даних? У чому відмінність етапів інфологічного та логічного проектування?
26. Що таке нормалізація відношень? Для чого вона використовується при проектуванні бази даних?
27. Чи завжди треба проводити максимально можливу нормалізацію відношень (приводити відношення до найвищої нормальної форми) при проектуванні бази даних?
28. Що таке сховище даних? Чим воно відрізняється від традиційної бази даних?
29. Які архітектури використовують при побудові сучасних сховищ даних?
30. Що таке простір даних і як здійснюється керування ним?
Розділ 5
КОНЦЕПЦІЇ РОЗВИТКУ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
