Інформаційно-комунікаційне забезпечення фінансової діяльності навчальний посібник

Лінійне уявлення на площині відображено на рис. 3.1.

а) зірка

б) сніжинка

в) сузір'я

Рис. 3.1. Лінійне подання схем багатовимірних даних

У багатовимірному полі інформації створюється велика центральна таблиця, так звана таблиця факту (fact table). У ній містяться всі дані щодо узагальнюючого показника, який цікавить користувача. Її оточують менші таблиці, що містять дані за ознаками, які називаються таблицями розмірності або іноді "таблицями-вимірниками" (dimensional table) [71].

Таблиці розмірності є батьківськими відносно таблиць факту. Таблиця факту є дочірньою. Можуть бути також консольні таблиці (outrigger table). Вони приєднуються до таблиць розмірності й деталізують окремі атрибути. Консольні таблиці є батьківськими відносно таблиць розмірності.

Таблиці фактів містять числові або якісні (змістові) значення.

71

Упроцесі розробки бази даних за схемою "зірка" або за іншою багатовимірною схемою необхідно глибоко й ретельно проаналізувати предметну область; помістити в центральну таблицю фактів усі дані, що характеризують досліджуваний об'єкт, попередньо розробивши систему ознак.

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

Схема "зірка" складається тільки з таблиць розмірності й таблиці факту. Розвитком схеми "зірка" є схема "сніжинка" (snowflake schema). Вона відрізняється від першої схеми великою кількістю консольних таблиць, які є практично на кожній таблиці розмірності й можуть мати кілька рівнів ієрархії.

Схема "сузір'я" (fact constellation schema) виходить з декількох таблиць фактів. У цьому варіанті багатовимірної моделі через консольні таблиці або таблиці розмірності з'єднується кілька таблиць фактів, що відображають декілька об'єктів із загальними атрибутами.

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

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

3.3. Концепції організації збереження даних

Індустрія створення баз даних і СУБД бере свій початок у 60-х роках минулого століття і дотепер досить розвинена, проте поняття "сховище даних" в сучасному його розумінні з'явилося відносно недавно.

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

72

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

До кінця 1980-х років, коли була повною мірою усвідомлена необхідність інтеграції корпоративної інформації та належного управління цією інформацією, з'явилися технічні можливості для створення відповідних систем, які спочатку були названі "сховищами інформації" (Information Warehouse – IW). І лише в 1990-ті роки, з виходом книги Б. Інмона, сховища отримали своє нинішнє найменування "сховища да-

них" (Data Warehouse – DW) [86].

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

Автор концепції DW виділяє такі характерні для них властивості

(табл. 3.2).

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

73

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

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

Реалізація концепції DW може бути здійснена кількома способами

[7; 140; 145].

Концепція централізованого сховища даних

Такий підхід означає, що за наявності декількох джерел інформації – операційних баз даних – створюється єдине централізоване сховище (рис. 3.2). У первинних джерелах інформація зберігається в "сирому", недопрацьованому вигляді, тобто у структурі інформаційного простору даного джерела інформації або операційної БД. Вся інформація, що надходить в DW, повинна бути перетворена в прийняту в даному DW структуру. Передача даних з операційних БД в DW, яка супроводжується доопрацюванням, може бути організована за заданим тимчасовим графіком і правилами доопрацювання. Допускаються несподівані запити "на льоту", що висувають більш суворі вимоги до інструментальних засобів DW.

Центральне сховище даних

Операційна		Операційна		...		Операційна
база 1		база 2				база N

Рис. 3.2. Схема централізованого сховища даних

У процесі реалізації такої концепції виникає потреба в потужному комп'ютері. Залежно від масштабів предметної області це буде або пер-

74

сональний комп'ютер з гранично високими характеристиками, особливо в частині вимог до обсягів пам'яті або мейнфреймів, і навіть суперкомп'ю- тер. Необхідна наявність розвинених засобів телекомунікацій, що забезпечують інформаційний обмін "операційні БД – DW". Ця вимога стосується будь-якого варіанта концепції DW.

Концепція розподіленого сховища даних

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

Інформаційне сховище 2

	Інформаційне сховище 1	Операційна	Операційна
		база 2 1	база 2 M

Операційна	Операційна	Інформаційне сховище 3
база 1 1	база 1 N

Операційна база 3 1

Операційна база 3 K

Рис. 3.3. Схема розподіленого інформаційного сховища

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

75

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

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

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

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

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

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

Концепція автономних вітрин даних

Одним із варіантів організації централізованого збереження і подання інформації є концепція вітрин даних (Data Mart). Вона запропонована Forrester Research у 1991 році. За такого підходу інформація, що стосується великої предметної області, наприклад інформаційний простір великої корпоративної системи, яка має кілька досить самостійних напрямів діяльності, групується за напрямами в спеціально організованих базах даних, які називають вітринами даних. Цей підхід є розвитком концепції розподіленого інформаційного сховища в частині надання функцій предметної орієнтованості деяким локальним ІС (рис. 3.4).

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

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

76

Вітрина даних 1

суміщена з ІС

Вітрина даних 2

суміщена з ІС

Вітрина даних M

суміщена з ІС

Операційна			Операційна					Операційна
база 1			база 2					база 3

Операційна	Операційна
база 4	база N

Рис. 3.4. Схема автономних вітрин даних

Концепція єдиного інтегрованого сховища і багатьох вітрин даних

У 1994 році M. Демарсет запропонував об'єднати дві концепції: єдиного інтегрованого сховища і вітрин даних, пов'язаних із ним (рис. 3.5). У такому варіанті є велике інформаційне сховище агрегованої та детальної інформації, яке може задовольнити потенційні запити з окремих напрямів діяльності.

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

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

77

Вітрина даних 1		Вітрина даних 2		Вітрина даних N

Центральне інформаційне сховище

Операційна		Операційна		Операційна		Операційна
база 1		база 2		база 3		база N

Рис. 3.5. Схема центрального інформаційного сховища

та багатьох вітрин даних

У такому варіанті ІС набуває ієрархічної багаторівневої структури, що містить наступні рівні:

загальнокорпоративне централізоване сховище даних; вітрини даних за напрямами діяльності; локальні або регіональні бази і сховища даних;

операційні бази даних, автоматизовані робочі місця користувачів автономних програм і АІС.

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

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

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

вимог та підходів до виконання аналізу, способів подання даних в ІС – у реляційній або багатовимірній формі.

78

3.4. Сучасні системи збереження даних

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

Обсяги збережених даних зростають експоненціально. Спроба виконати вимогу надійності збереження даних та їх доступності за певний час призводить до зростання обсягів сховищ на кілька порядків. І це завдання не може бути вирішене виключно за рахунок збільшення ємності дисків навіть у разі зниження їх вартості. Якщо методи обробки даних змінюються досить швидко – синхронно зі зміною серверного парку, тобто приблизно раз на п'ять років, то методи збереження даних повинні забезпечувати зворотну сумісність на строк, що дорівнює часу існування основної частини інформації, а це вже періоди порядку 25 – 250 років і більше.

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

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

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

Основними проблемами, які вирішуються МЗД є наступні [37; 65; 72; 75; 80]:

1. Децентралізація інформації. Якщо раніше всі дані могли зберігатися на жорсткому диску, то зараз будь-яка функціональна система пот-

79

ребує окремого сховища, наприклад, серверів електронної пошти, БД, інтернету та ін.

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

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

4.Неефективна утилізація ресурсів. Так, на сервері електронної пошти може зберігатися безліч листів, що вже не потрібні користувачу.

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

6.Складність управління розподіленими потоками інформації.

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

7.Низький економічний ефект впровадження "класичних" рішень.

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

80