Структура сховищ даних та програмні засоби роботи зі сховищами даних

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

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

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

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

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

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

Враховуючи специфіку, cховище даних має такі особливості проектування та побудови:

1) отримання інформації з різних джерел даних (у тому числі і з реляційних баз даних) у деталізованому та аґреґованому вигляді (зберігаються результати застосування функцій агрегації – суми, середнього значння, максимуму, мінімуму тощо);

2) багатовимірне подання інформації – ігноруються деякі вимоги нормалізації (дотримують максимум 3-ої нормальної форми), що значно підвищує швидкість опрацювання інформації, оскільки зменшує кількість операцій з’єднання;

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

4) наявність пакетного завантаження даних в сховище даних та вивантаження даних;

5) наявність процедур аналізу даних та отримання нових даних;

6) орієнтованість даних на аналітичне, а не на статичне опрацювання.

Сховища даних краще пристосовані до зберігання та аналітичного опрацювання великих обсягів даних і, в основному, є інтеґрацією реляційної та багатовимірної моделей. На сьогодні є такі архітектури побудови сховищ даних: корпоративна інформаційна фабрика Білла Інмона, шина Ральфа Кімбола, зведення даних корпорації TDAN. Вони мають розвинені засоби інтеґрації даних з різних джерел та дозволяють працювати як з деталізованою, так і аґреґованою інформацією.

Парадигма для реляційних даних в сховищі даних (парадигма корпоративної інформаційної фабрики КІФ – Corporate Information Factory, CIF) розроблена Інмоном і передбачає, що дані повинні перебувати на низькому рівні ступені деталізації і в третій нормальній формі (3НФ, 3NF). Білл Інмон підтримує повторний або спіральний підхід до розвитку великого сховища даних. За цим підходом розвиток сховища відбувається ітераційно, тобто у разі виникнення потреби додається одна таблиця за один раз, що забезпечує лише незначну зміну схеми даних. Тому такий підхід до проектування сховища ще називають спіральним підходом.

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

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

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

Матриця корпоративного сховища даних з архітектурою шини виявляє
й підсилює зв'язок між показниками бізнес-процесів (фактами) і описовими атрибутами (вимірами).

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

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

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

Є такі підвиди сховища даних: вітрина даних, оперативне сховище даних.

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

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

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

 по-перше, воно є джерелом аналітичної інформації для оперативного керування,

 по-друге, тут підготовляються дані для наступного завантаження в центральне сховище.

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

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

Архітектура сховища даних. Архітектура сховища даних розглядається з точки зору чотирьох рівнів:

- рівень користувача – описує програмний інтерфейс доступу користувачів до сховища даних;

- рівень застосувань (ППЗ) – описує засоби роботи з даними;

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

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

Джерела інформації. Джерелами даних для сховища даних ДПС є:

Дані систем сегментів операційної діяльності ДПС:

- Реєстрація платників податків;

- Обробка податкової звітності та платежів;

- Облік платежів;

- Податковий аудит;

- Управління персоналом;

- Обслуговування платників податків;

- Апеляції платників податків;

- Погашення податкового боргу;

- Внутрішній контроль;

- Досудове слідство (кримінальні розслідування);

- Розробка автоматизованої системи декларування, обліку і контролю виробництва, зберігання, руху та споживання підакцизних товарів;

- Вирішення справ у господарських судах за участю органів ДПС;

- Матеріально-технічне та фінансове забезпечення;

- Зв‘зки з громадськістю;

- Розробка проектів нормативно-правових актів та впровадження законодавства;

- Організація боротьби з відмиванням доходів одержаних злочинним шляхом.

архіви;

- внутрішні файли, що прямо не пов‘язані з оперативними системами – індивідуальні робочі електронні таблиці, робочі журнали;

- зовнішні джерела – дані від зовнішніх організацій відповідно до угод/протоколів/наказів про інформаційну взаємодію ДПА України з відповідною організацією: (Мінфін, Мінекономіки, Держмитслужба, Держказначейство, ГоловКРУ, Держкомстат, Держпідприємництво, НБУ інші).

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

- достовірність;

- повнота;

- несуперечливість;

- ненадлишковість;

- актуальність;

- цілісність;

- надіндексованість;

- денормалізованість.

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

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

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

Інформаційна інфраструктура ДПС, яка включатиме сховище даних, у загальному вигляді включає:

- існуючі оперативні системи (АРМи та АІС), як джерела даних;

- проміжне середовище, як місце очищення та перетворення даних;

- аналітичне ППЗ, як засоби створення запитів до даних та отримання звітів, результатів розрахунків складних математичних та статистичних моделей;

- вітрини даних, як сукупність даних відповідної сфери діяльності;

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

Опис інформації. Важливий аспект у розробці сховища даних пов'язаний із створенням репозиторію метаданих – „дані про дані”. Застосовуючи дане визначення до сховищ даних, мають на увазі, що метадані – це „мапа” розташування даних в сховищі даних.

Виділяють три види метаданих сховища:

- метадані оперативних систем – використовуються в процесах управління завантаженням та доступом до джерел даних;

- метадані кінцевих користувачів – описують розміщення та структуру даних, об‘єми даних та алгоритми, тобто є навігатором по даним сховища для кінцевого користувача;

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

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

- OLAP (On-line Analytical Processing), інтерактивний оперативний аналіз даних — застосування, що підтримує багатовимірне представлення даних з метою оперативного аналізу і підготовки звітів, полегшує навігацію користувачів у множині вимірів та ієрархій всередині вимірів;

- Reporting – формування звітів за шаблонами попередньо визначених форм та за довільними формами;

- Ad-Hoc Reporting – отримання інформаційних виборок у відповідь на довільні запити аналітиків;

- Business Intelligence, BI – процес перетворення даних в інформацію, а інформацію в знання, тобто метою ВІ є перетворення множини даних в корисну для роботи інформацію;

- Data Mining – інтелектуальний аналіз даних – процес аналізу великих масивів даних, застосовується для виявлення зв'язків між різними їх елементами та пошуку схованих закономірностей;

- побудова складних математичних та статистичних моделей.

Служби доступу до даних. Основним призначенням служб доступу до даних є надання програмним засобам інтерфейсу, який дозволяє передавати SQL-запити до сховища даних для отримання потрібної інформації. При розробці власних застосувань вибір типу та постачальника інтерфейсу доступу до даних (JDBC, ODBC, ADO, OLE DB) на пряму залежить від обраної програмної платформи сховища даних. Тип інтерфейсу доступу до даних додатково залежить від типу об’єктів, до яких звертається застосування (наприклад, для доступу до каталогів OLAP на СКБД ORACLE доречно використовувати інтерфейс JDBC:OCI). Для стандартизації доступу до ресурсів даних рекомендовано використовувати служби імен та каталогів (JNDI, ODI, AD), вибір яких теж залежить від обраної програмної платформи.

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

Для виконання регулярних завантажень можливо використовувати один з методів – створення власних програм (алгоритмів), використання готового спеціалізованого інструментарію ETL, використання інструментарію СКБД або операційних систем. Ініціювання завантаження може відбуватись як за розкладом, так і за системною подією.

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

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

Таблиця 5.1.2.

5.2. Робота з базами даних засобами MS Office

Поиск по сайту: