1. Repository at ChSTU
  2. Випускні кваліфікаційні роботи
  3. Магістр
  4. 174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)
Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/6411
Title: Дослідження архітектур побудови автоматизованих систем аналізу великих даних
Authors: Міценко, Сергій Анатолійович
Комісаренко, Назар Анатолійович
Issue Date: Jan-2023
Abstract: У кваліфікаційній роботі магістра розв’язано важливе наукове завдання розроблення методів та засобів організації та інтеграції інформаційних ресурсів Великих даних для автоматизованого процесу управління даними. Проаналізовано методи, моделі та засоби опрацювання різнотипних даних, інформаційних технологій роботи з Великими даними. Обґрунтовано актуальність розв’язання завдання організації та інтеграції інформаційних ресурсів Великих даних у розподілених системах даних. Створено інформаційну модель Великих даних «сутність-характеристика», яка дає змогу організовувати структуровані та слабоструктуровані дані і на відміну від багатовимірної моделі не містить надлишковості. Удосконалено метод перетворення реляційних та слабоструктурованих даних у дані, подані в моделі «сутність-характеристика», що дало змогу уніфікувати форму запитів до різних моделей даних. Удосконалено метод інтеграції даних через визначення пари «сутність-характеристика» та узгодження семантики, що на відміну від методів інтеграції даних на рівні сховища даних дозволило інтегрувати дані з джерел з наперед невідомою структурою без попереднього локального завантаження, і що, в свою чергу, дало змогу підвищити ефективність подальшого аналізу Великих даних. Даний метод став основою для оптимізації формування відповіді на запит користувача. Удосконалено метод формування відповіді на запит користувача до Великих даних шляхом уніфікації елементів мов запитів до різних інформаційних джерел, що дало змогу трансформувати запит до Великих даних у запит на основі ключових слів. Розроблено компоненти інформаційної системи підтримки прийняття рішень для автоматизованого управління інформацією з використанням Великих даних.
URI: https://er.chdtu.edu.ua/handle/ChSTU/6411
Appears in Collections:174 Автоматизація, комп'ютерно-інтегровані технології та робототехніка (Автоматизація та комп'ютерно-інтегровані системи та компоненти)

Files in This Item:
File Description SizeFormat 
М_151_2022_Комісаренко.pdf
  Restricted Access		1.51 MBAdobe PDFView/Open Request a copy
Show full item record


Items in DSpace are protected by copyright, with all rights reserved, unless otherwise indicated.

Extracted text 
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ 
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ 
КАФЕДРА РОБОТОТЕХНІКИ ТА СПЕЦІАЛІЗОВАНИХ КОМП’ЮТЕРНИХ 
СИСТЕМ 
 
 
 
 
Пояснювальна записка 
до кваліфікаційної роботи 
освітнього ступеню «магістр» 
 
 
на тему: ДОСЛІДЖЕННЯ АРХІТЕКТУР ПОБУДОВИ 
АВТОМАТИЗОВАНИХ СИСТЕМ АНАЛІЗУ ВЕЛИКИХ ДАНИХ 
 
 
 
 
Виконав: студент 2 курсу, групи МАКІТ-2109 
спеціальності 151 Автоматизація та 
комп’ютерно-інтегровані технології,  
освітня програма «Комп’ютерно-
інтегровані технологічні процеси і 
виробництва» 
      Комісаренко Н.А.        
(прізвище та ініціали) 
 
Керівник        Міценко С.А.           
      ( прізвище та ініціали)   
 
Рецензент              
            (прізвище та ініціали) 
   
 
 
Черкаси 2022 року 
2 
ЗМІСТ 
 
 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ ........................................................................ 3 
ВСТУП ......................................................................................................................... 4 
РОЗДІЛ 1 АНАЛІТИЧНИЙ ОГЛЯД СТРУКТУРИ ВЕЛИКІ ДАНІ ...................... 8 
1.1. Аналіз проблем опрацювання різнотипної інформації ................................ 8 
1.2. Визначення терміну Великі дані .................................................................. 11 
1.3. Концепції роботи з Великими даними ......................................................... 15 
1.4. Математичні методи подання Великих даних ............................................ 25 
1.5. Постановка задачі дослідження .................................................................... 30 
Висновки ................................................................................................................ 31 
РОЗДІЛ 2 МОДЕЛЬ ВЕЛИКИХ ДАНИХ ДЛЯ АВТОМАТИЗОВАНИХ 
СИСТЕМ УПРАВЛІННЯ ......................................................................................... 33 
2.1. Типи моделей даних для представлення Великих даних ........................... 33 
2.2. Формальний опис структури Великих даних .............................................. 47 
2.3. Моделі асоціацій між сутностями та характеристиками для різних 
категорій NoSQL баз даних .................................................................................. 50 
Висновки ................................................................................................................ 53 
РОЗДІЛ 3 УДОСКОНАЛЕННЯ МЕТОДУ АНАЛІЗУ ДАНИХ В МОДЕЛІ 
«СУТНІСТЬ-ХАРАКТЕРИСТИКА» ....................................................................... 54 
3.1. Використання простору даних для моделювання Великих даних ............ 54 
3.2. Модель сховища Великих даних .................................................................. 58 
3.3. Удосконалення методу перетворення даних в модель «сутність-
характеристика» .................................................................................................... 64 
3.4. Розроблення засобів інтеграції даних та їх аналізу .................................... 67 
Висновки ................................................................................................................ 70 
ЗАГАЛЬНІ ВИСНОВКИ .......................................................................................... 72 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ ................................................................. 74 
3 
ПЕРЕЛІК УМОВНИХ СКОРОЧЕНЬ 
 
 
CCP – Compute Cluster Pack 
COMA – Сache-only memory architecture 
FIPA – Foundation for Intelligent Physical Agents 
HDFS – Hadoop Distributed File System 
IoT – Internet of Things (Інтернет речей) 
MIMD – Multiple Instruction Multiple Data 
MPI – Message Passing Interface 
MАС – Мультиагентна система 
MРР – Massive Parallel Processing 
NORMA – Non-Remote Memory Access 
NUMA – Non-cache coherent 
PVM – Parallel Virtual Machine 
QoS – Quality of service (якість обслуговування) 
SMP – Symmetric multiprocessor 
SOA – Service Oriented Apllication 
TTL – Temporal Trace Language 
БД – База даних 
БОС – Багатопроцесорна обчислювальна система 
ІТ – Інформаційна технологія 
КС – Комп’ютерна система 
ОС – Операційна система 
ПЗ – Програмне забезпечення 
РКС – Розподілена комп’ютерна система 
СППР – Система підтримки прийняття рішень 
4 
ВСТУП 
 
 
Актуальність. Застосування інформаційних систем розвитку сприяє 
швидкому поширенню знань, навичок та найкращих практик у певних галузях 
промисловості. Для комплексного аналізу інформації необхідно: зберігати і 
керувати інформацією розміром у петабайти; опрацьовувати інформацію з 
реляційних, багатовимірних баз даних, баз даних XML і NoSQL, структурованих 
і слабоструктурованих текстових файлів, баз геоданих, медіафайлів тощо; 
аналізувати різнотипну інформацію, використовуючи як консолідований, так і 
підхід для її отримання. 
Процес побудови узагальненої (комплексної) моделі ускладнюється 
різноманітністю моделей даних, а також через наявність різних рівнів агрегації 
даних. Однією з популярних технологій для розроблення автоматизованих 
систем управління є Великі дані. 
Великі дані є терміном, який використовується для ідентифікації наборів 
даних, з якими не можна впоратися з використанням існуючих методологій та 
програмних засобів через їх великий розмір і складність. Такі дослідники як 
М. Гілбернт [10], С. Стрініваса [15] та ін. розробили методики і програмні засоби 
для передачі даних або видобування інформаційних гранул з Великих даних 
(колекції об’єктів, які зазвичай формуються для атрибутів з числовими даними і 
які розташовані поряд через їх схожість, функціональну або фізичну суміжність). 
Методи машинного навчання та візуалізації даних дають змогу опрацювати та 
графічно подати результати аналізу даних великих обсягів (мільойони кортежів). 
Проте нерозв’язаною задачею залишається задача побудови відображення між 
моделями даних різних джерел. В роботах Alejandro Maté [14] та Lucentia 
Research Group [5] обґрунтовано використання багатовимірної моделі для 
представлення Великих даних та побудови відображення в реляційну модель. 
Проте у випадку використання бази даних ключ-значення як однієї з джерел 
даних застосування багатовимірної моделі неприйнятне. Vinayak Borkar [13], 
5 
Yingyi Bu [32] пропонують використовувати об’єктно-орієнтований підхід, 
проте обмеженням є кількість зв’язків між об’єктами. Отже, єдиного підходу до 
опрацювання Великих даних не знайдено.  
Грунтуючись на цій інформації, з метою її подальшого аналізу, слід 
вирішити питання, які сутності і в який спосіб пов’язані між собою. Тому задача 
розроблення методів та засобів опрацювання Великих даних в автоматизованих 
системах управління є актуальною. 
Мета роботи – розробка методів та засобів опрацювання та аналізу 
різнорідної інформації на основі Великих даних для процесів автоматизованого 
управління. 
Мета роботи визначає необхідність розв’язання таких задач: 
− проаналізувати методи, моделі та засоби опрацювання різнотипних 
даних, інформаційні технології роботи з Великими даними, 
обґрунтування й постановка задачі; 
− розробити інформаційну модель Великих даних «сутність-
характеристика»; 
− удосконалити метод перетворення реляційних та слабоструктурованих 
даних у дані, подані в моделі «сутність-характеристика»; 
− удосконалити метод формування відповіді на запит користувача до 
Великих даних; 
− розробити компоненти інформаційної системи підтримки прийняття 
рішень для автоматизованого управління з використанням Великих 
даних. 
Об’єкт дослідження – процес інтеграції слабоструктурованих даних, 
виділення елементів структури, та збереження їх у базу даних. 
Предмет дослідження – архітектури побудови автоматизованих систем 
аналізу великих даних 
Методи дослідження. Для досягнення поставленої мети 
використовувались: методи системного аналізу – для формування 
концептуальної моделі Великих даних; методи штучного інтелекту – для 
6 
виявлення закономірностей у каталозі Великих даних; методи об’єктно-
орієнтованого аналізу та проектування – для визначення семантичних зв’язків 
між джерелами даних. 
Наукова новизна роботи полягає у розв’язанні актуального наукового 
завдання розроблення методів та засобів організації та інтеграції інформаційних 
ресурсів Великих даних. Отримано наступні наукові результати: 
− удосконалено модель Великих даних «сутність-характеристика», яка 
дає змогу опрацьовувати структуровані та напівструктуровані дані та 
на відміну від багатовимірної моделі не містить надлишковості; 
− удосконалено отримання відповіді на запит користувача шляхом 
уніфікації елементів мов запитів до різних інформаційних джерел, що 
дало змогу трансформувати запит до Великих даних у запит на основі 
ключових слів; 
− одержав подальший розвиток метод інтеграції даних за рахунок 
визначення пари «сутність-характеристика» та узгодження семантики, 
що на відміну від методів інтеграції даних на рівні сховища даних 
дозволило інтегрувати дані з джерел з наперед невідомою структурою 
даних без попереднього локального завантаження і що, в свою чергу, 
дало змогу підвищити ефективність подальшого аналізу Великих 
даних. 
Практичне значення отриманих результатів полягає у тому, що: 
− удосконалено алгоритми інтеграції інформаційних ресурсів за 
допомогою попереднього визначення структури джерел даних та їх 
узгодження, що дало можливість розробити алгоритм оцінювання 
якості Великих даних; 
− розроблено алгоритми пошуку даних за запитом користувача з метою 
уніфікації алгоритмів опрацювання даних з різнотипних джерел даних, 
що дозволило збільшити релевантність відповіді користувачеві на 2%; 
− спроектовано архітектуру інформаційної системи для роботи з 
Великими даними. 
7 
Апробація результатів роботи. Результати кваліфікаційної роботи 
доповідалися й обговорювалися на студентських і наукових конференціях: 
− дні студентської науки ЧДТУ, 20-21 квітня, м. Черкаси, 2021; 
− дні студентської науки ЧДТУ, 19-20 квітня, м. Черкаси, 2022; 
− «Проблеми інформатизації»: Тези доповідей десятої міжнародної 
науково-технічної конференції: (24-25 листопада 2022 р., Черкаси), 
2022. – С. 44. 
Публікації. Результати досліджень опубліковані в: 
1. Архітектури побудови автоматизованих систем аналізу великих даних 
/ Міценко С.А., Комісаренко Н.А., Корнієнко А.Д. // «Проблеми 
інформатизації»: Тези доповідей десятої міжнародної науково-
технічної конференції: (24-25 листопада 2022 р., Черкаси), 2022. – 
С. 44. 
Структура та обсяг кваліфікаційної роботи. Кваліфікаційна робота 
складається із списку умовних скорочень, вступу, трьох розділів, висновку та 
списку використаних джерел. Загальний обсяг роботи складає 81 сторінки, 
18 рисунків, 3 таблиці. Список використаних джерел містить 61 найменування. 
8 
РОЗДІЛ 1 
АНАЛІТИЧНИЙ ОГЛЯД СТРУКТУРИ ВЕЛИКІ ДАНІ 
 
1.1. Аналіз проблем опрацювання різнотипної інформації 
Проблема швидкого отримання різнотипових даних (сенсорних числових, 
текстових документів, графіків тощо) з метою формування на їх основі 
оперативних рішень постала ще у роки 2-ї світової війни і активно розвивалась 
для застосування в атомних проектах, управлінні ракетами, навігації, управлінні 
бойовими діями. 
Опрацювання та аналіз таких різнотипових даних використовується для 
моделювання розвитку подій та ситуацій, а також в системах підтримки 
прийняття рішень. Започаткували вивчення цієї проблеми фон Нейман, розробки 
компанії IBM, науковці школи Лєбєдєва С.О. (спеціалізована ЕОМ), Глушкова 
В.М. (системний аналіз, теорія конфліктних ігор, проблемноорієнтовані системи 
моделювання та опрацювання даних) [1, 5], що призвело до розвитку мов 
блокового програмування, систем підтримки прийняття рішень. 
Проте зміна класу досліджень – від оперативного до аналітичного, поява 
нових типів даних, необхідність швидкого доступу до них, зумовила збільшення 
інтересу до проблеми інтеграції та опрацювання даних з метою підвищення 
якості управлінських рішень. Найвищий пік активності досліджень у сфері 
інтеграції припадає на 90-ті рр. XX ст. та на наш час [54] у зв’язку з бурхливим 
розвитком методів Business Intelligence та збільшенням можливостей сховищ 
даних (збільшення обсягів збережених даних, наявність процедур аналітичного 
опрацювання даних – OLAP). 
Особливістю сучасних досліджень є аналіз не лише типів даних (описів), 
але й семантики. Особливо активний розвиток засобів для оперативного збору 
різнотипних даних, завантаження їх у сховище даних, аналізу та прогнозування 
спостерігається в сферах енергетики та адміністративного керування, 
нафтогазовому секторі [53]. 
9 
Схема отримання інформації органами керування регіоном передбачає 
створення статистичних звітів іншими об’єктами галузі за наперед визначеною 
формою з покроковим агрегуванням інформації від одного об’єкту до іншого 
(рис. 1.1). 
 
 
Рис. 1.1. Схема рівноправного обміну даними 
 
Це приводить до того, що особа, яка отримує інформацію, бачить її лише в 
агреговану вигляді за жорстко визначеними критеріями групування, а 
деталізована інформація потрапляє зі значним запізненням. Тому рішення, які 
можуть бути прийняті у такому випадку, недостатньо враховують усі 
особливості перебігу процесів розвитку регіону. 
Процес консолідації даних для аналізу та прогнозування розвитку регіону 
генерує наступні задачі: 
− підвищення оперативності отримання, аналізу та використання 
інформації, необхідної для підтримання прийняття рішень щодо 
керування регіоном; 
10 
− підвищення якості та дієвості керуючих рішень завдяки оперуванню 
достовірною інформацією, отриманою безпосередньо з відповідного 
джерела; 
− визначення нових аспектів діяльності регіону завдяки аналізу даних, 
які не потрапляли у традиційні звіти, і тому не враховувалися при 
прийнятті рішень; 
− своєчасного виявлення негативних тенденцій розвитку з метою їх 
подальшого усунення. 
Інформаційний бум призвів до збільшення кількості даних, накопичених у 
багатьох предметних галузях у сотні та тисячі разів. До таких областей 
відноситься і сфера державного управління. Кількість зібраної інформації 
зростає експоненційно. Так, за дослідженням IDC Digital Universe Study [41], 
проведеним на замовлення компанії EMC, сумарний обсяг світових даних у 2005 
році складав 130 ексабайт, до 2011 року він зріс до 1227 EB, а за останній рік 
знову подвоївся, досягши 3 ZB (зетабайт). Прогноз, здійснений тим же 
дослідженням, показує, що до 2018 року обсяг цифрових даних зросте до 7.9 ZB. 
Розмір окремих баз даних зростає так само швидко і подолав петабайтний бар’єр. 
Більшість зібраних даних на даний час не аналізується, або ж проходить лише 
поверхневий аналіз [52]. 
Видобування даних є процесом виявлення нових нетривіальних 
закономірностей з великих масивів інформації. Необхідно зазначити, що 
прикметник «великий» у застосуванні до даних має тенденцію до постійного 
зростання значення. Наприклад, за даними Тіма Суонсона кількість операцій, що 
здійснюється щодня в криптовалюті Bitcoin, перевищила 100 000 операцій. 
Очевидно, що таку кількість даних неможливо опрацювати без використання 
автоматизованих засобів. Тому фахівцями розроблено багато методів аналізу 
даних, пошуку залежностей між ними, прогнозування тощо. 
Основними проблемами, які виникають при обробці даних, є відсутність 
методів аналізу, придатних до застосування через їх різнотипність (для регіону– 
це і числові дані, і гео-дані, слабоструктуровані звіти тощо), потреба у значних 
11 
людських ресурсах для підтримки процесу аналізу даних, висока обчислювальна 
складність наявних алгоритмів аналізу та стрімке зростання обсягу зібраних 
даних. Це в свою чергу призводить до постійного зростання часу, що 
витрачається на аналіз даних навіть при регулярному оновленні комп’ютерних 
засобів, а також – необхідність роботи із розподіленими базами даних, 
можливості яких більшість існуючих методів аналізу даних не використовують 
ефективно. 
Таким чином, виникає задача розроблення ефективного методу аналізу 
даних, що може застосовуватись до розподілених баз даних різних предметних 
областей. Тому для регіону доцільно розробляти методи та засоби консолідації 
даних та використання їх для аналізу. 
 
1.2. Визначення терміну Великі дані 
Концепція Великих даних не нова, вона виникла за часів мейнфреймів і 
пов’язаних з ними наукових обчислень [136, 138]. Як добре відомо, 
наукомісткість обчислень завжди було складним завданням. Як правило, вона 
нерозривно пов’язана з обробкою великих обсягів інформації. 
Проте, безпосередньо термін «Великі дані» (Big Data) з’явився порівняно 
недавно. Він є одним з небагатьох, що має відомий день народження – 3 вересня 
2008 р. Тоді було випущено спеціальний випуск найстарішого британського 
наукового журналу Nature. Журнал присвячений пошукам відповіді на питання: 
«Як технології можуть вплинути на наукове майбутнє, що відкриває можливості 
для роботи з Великими даними» [35]. 
Згідно зі звітом McKinsey інституту під назвою «Великі дані: Наступний 
рубіж для інновацій, конкуренції і продуктивності», термін «Великі дані» 
відноситься до наборів даних, розмір яких перевищує ємність звичайної бази 
даних (БД) для видобування, зберігання, управління і аналізу інформації [15]. 
Глобальні сховища даних продовжують зростати. Представлений звіт 
аналітичної компанії IDC під назвою «Digital Universe Study» в середині 
2011 року (який був організований компанією EMC) [41] передбачає, що 
12 
загальний світовий обсяг генерованих і тиражованих даних може досягати в 2011 
році близько 1,8 зеттабайт (1,8 трлн гігабайт ). Це приблизно в 9 разів більше, 
ніж те, що було створено в 2006 році [41]. 
Проте, концепт «Великі дані» означає набагато більше, ніж просто 
величезні обсяги інформації. Проблема полягає не в тому, що організації 
генерують величезні обсяги даних, але більшість з них представлені в форматі, 
який не дуже добре вписується в традиційний структурований формат бази 
даних. Це веб-журнали, відео, текстові документи, машинний код, або, 
наприклад, картографічні дані.  
У результаті, корпорація може мати доступ до величезного обсягу своїх 
даних і не мати необхідних інструментів для встановлення зв’язків між цими 
даними, автоматизованого формулювання  конструктивних висновків на основі 
аналізу цих даних.  
Крім того, дані зараз оновлюються частіше, і ми маємо ситуацію коли 
традиційні методи аналізу інформації не можуть опрацювати величезні обсяги 
даних, що постійно оновлюються, і це, в кінцевому рахунку, прокладає шлях для 
технологій Big Data. 
EWeek подає визначення, запропоноване дослідницькою компанією 
Gartner: «Великі дані характеризуються обсягом, різноманітністю і швидкою 
плинністю структурованих і неструктурованих даних в процесорах і пристроях 
зберігання даних, а також перетворення даних для задач бізнес-консалтингу для 
підприємств» [52]. 
Великі дані (Big Data) в інформаційних технологіях за визначенням К. 
Лінч, Д. Леней – набір методів та засобів опрацювання структурованих і 
неструктурованих різнотипних динамічних даних великих обсягів з метою їх 
аналізу та використання для підтримки прийняття рішень [52].  
Є альтернативою традиційним системам управління базами даних і 
рішенням класу Business Intelligence. До цього класу відносять засоби 
паралельного опрацювання даних (NoSQL, алгоритми MapReduce, Hadoop) [48]. 
13 
На думку компанії DCA (Data-Centric Alliance) під Big Data розуміють не 
якийсь конкретний об’єм даних і навіть не дані, а методи їх обробки, які 
дозволяють розподілено обробляти інформацію [11].  
Ці методи можна застосовувати як до великих масивів даних (таких як дані 
всіх сторінок в мережі Інтерет), так і до малих масивів (інформація про денні 
поступлення товару в магазин). 
Визначальними характеристиками для Великих даних є [47] обсяг (volume, 
в сенсі величини фізичного обсягу), швидкість (velocity в сенсах як швидкості 
приросту, так і необхідності високошвидкісної обробки та отримання 
результатів), різноманіття (variety, в сенсі можливості одночасної обробки різних 
типів структурованих і слабоструктурованих даних). 
Хмарні технології підтримують інфраструктуру віртуалізації та її 
профілювання для конкретних структур даних або для підтримки конкретних 
наукових робочих процесів [56]. 
Розмаїтість (Variety) визначається за допомогою [46]: 
1 реляційних даних (таблиці / транзакції); 
2 текстових даних (Web),напівструктурованих даних (XML); 
3 даних на основі графових моделей (соціальна мережа, Semantic Web, 
RDF); 
4 потокових даних; 
5 великих публічних даних (онлайн, погода, фінанси і т.д.). 
Є такі види вартості (Value) у Великих даних як статистичні дані, події, 
метадані тощо. 
Швидкість (Velocity) (Speed) Великих даних подана як: 
1 дані генеруються швидко і повинні бути опрацьовані швидко; 
2 он-лайн аналіз даних; 
3 підтримка прийняття рішень з неповними даними. 
Достовірність (Veracity) – поняття, зворотне до невизначеності, яка 
виникає через невідповідність даних, їх неповноту, латентність [49].  
14 
Аналіз даних в системах територіального управління зводиться до 
вирішення трьох конкретних завдань: 
− соціально-економічна оцінка стану природного середовища в регіоні в 
даний час і перспективі, розроблення на її основі системи заходів по 
повному запобіганню чи максимальному пом’якшенню негативного 
впливу господарської діяльності на навколишнє середовище; 
− визначення й врахування можливих наслідків змін у природному 
середовищі в результаті господарської діяльності і техногенних 
процесів, їх вплив на спеціалізацію і комплексний розвиток 
господарства регіону; 
− врахування прогнозів еколого-економічних процесів у контексті 
загального комплексного прогнозу соціально-економічного розвитку 
регіону шляхом формування ряду критеріїв і обмежень як по ресурсах, 
так і за допомогою показників якісного стану навколишнього 
середовища. 
Незважаючи на те, що термін був введений в академічному середовищі, 
первинною була проблема зростання кількості і різноманітності наукових даних. 
Станом на 2009 рік термін став широко поширений у діловій пресі, а до 2010 
року з’явилася перша низка інформаційно-технологічних продуктів і рішень, що 
стосуються виключно проблем обробки великих обсягів даних. 
З 2011 року більшість найбільших постачальників інформаційних 
технологій для організацій в їх бізнес-стратегії використовують концепцію 
Великих даних, у тому числі IBM, Oracle, Microsoft, Hewlett-Packard , EMC [51]. 
Завдання, що виникають під час опрацювання, обробки, інтерпретації, 
збору та організації Великих даних, з’явилися в численних секторах, включаючи 
бізнес, промисловість, некомерційні організації. Обсяги даних, такі як операції 
замовника у роздрібній торгівлі, моніторинг погоди, бізнес-аналіз, можуть 
швидко випереджувати потужність традиційних методів та інструментів аналізу 
даних. З’явилися нові методи та інструменти, включаючи бази даних NoSQL, 
MapReduce, обробка природної мови, машинне навчання, візуалізація, 
15 
придбання, і серіалізація. Усе це стає необхідним, щоб повною мірою 
усвідомити, що відбувається, коли зростають Великі дані, як вони 
застосовуються і де починають відігравати вирішальну роль. Також необхідо 
знати вимоги до існуючих методів розроблення систем і аналізу даних. 
Великі дані є терміном, який використовується для ідентифікації наборів 
даних, з якими ми не можемо впоратися з використанням існуючих методологій 
та програмних засобів через їх великий розмір і складність. Багато дослідників 
намагаються розробити методики і програмні засоби для передачі даних або 
видобування інформаційних гранул з Великих даних [27, 54]. 
Особливості Великих даних, а саме: 
− робота з неструктурованою та структурованою інформацією; 
− орієнтація на швидке опрацювання даних; 
− призводять до того, що традиційні мови запитів виявляються 
малоефективними для роботи з даними [41]. 
Тому метою роботи є формальний опис різних моделей даних, виділення 
операцій та носіїв, а також способів їх сумісного використання. 
 
1.3. Концепції роботи з Великими даними 
Концепція NoSQL 
Однією з концепцій опрацювання не тільки реляційних даних є NoSQL 
[32]. Прихильниками концепції мови NoSQL підкреслюється, що вона не є 
повним запереченням мови SQL і реляційної моделі, що SQL – це важливий і 
досить корисний інструмент, але при цьому він не може вважатися 
універсальним. Однією з проблем, яку вказують для класичних реляційних БД, є 
проблеми при роботі з даними дуже великого обсягу, проектами з високим 
навантаженням. Основна мета підходу – розширити можливості БД там, де SQL 
недостатньо гнучкий, і не витісняти його там, де він справляється зі своїми 
завданнями. 
В основі NoSQL є такі фактори: 
− нереляційна модель даних; 
16 
− розподіленість; 
− відкритий вихідний код; 
− гарна горизонтальна масштабованість. 
У якості одного з методологічних обґрунтувань підходу NoSQL 
використовується евристичний принцип, відомий як теорема CAP (Consistence, 
Availability, Partition tolerance – «узгодженість, доступність, стійкість до 
поділу»), стверджуючий, що в розподіленій системі неможливо одночасно 
забезпечити узгодженість даних, доступність (англ. availability, у змісті наявності 
відповіді по будь-якому запиту) і стійкість до розщеплення розподіленої системи 
на ізольовані частини.  
Таким чином, за необхідності досягнення високої доступності й стійкості 
до поділу не фокусуються на засобах забезпечення узгодженості даних, що 
забезпечуються традиційними SQL-орієнтованими СУБД з транзакційними 
механізмами на принципах ACID [33]. 
Нестроге доведення теореми CAP засноване на простих міркуваннях. 
Нехай розподілена система складається з N серверів, кожен з яких обробляє 
запити деякого числа клієнтських застосунків. Під час опрацювання запиту 
сервер повинен гарантувати актуальність інформації, що міститься у відповіді на 
запит, що надсилається, для чого попередньо потрібно синхронізувати вміст його 
власної бази з іншими серверами. Т 
аким чином, серверу необхідно чекати повної синхронізації або генерувати 
відповідь з урахуванням не синхронізованих даних. Можливий і третій варіант, 
коли з яких-небудь причин синхронізація здійснюється тільки з частиною 
серверів системи. У першому випадку невиконаною є вимога стосовно 
доступності, у другому – узгодженості, у третьому – стійкості до поділу. 
Існує чотири категорії NoSQL баз даних [31]. 
Перша категорія – це Key-Value (Ключ-Значення) бази даних. Це дуже 
прості по своїй ідеї бази даних. Фактично це дуже великі хеш-таблиці, де 
кожному ключу поставлене у відповідність значення. Такі бази можуть дуже 
швидко оперувати колосальними обсягами інформації, але вони мають серйозні 
17 
обмеження в мові запитів. У якості прикладів Key-Value баз даних можна 
привести Dynomite, Voldemort, Tokyo, Redis. 
Друга категорія – клони Bigtable. BigTable – це база даних розроблена 
компанією Google для власних потреб. Ця база являє собою велику таблицю із 
трьома вимірами: колонки, рядки й часові мітки. Така архітектура дозволяє 
добитися дуже високої продуктивності, крім того, вона добре масштабується на 
багато комп’ютерів. Але це нереляційна база даних, і вона не підтримує багато 
можливостей реляційних баз даних. Зокрема в Bigtable немає операцій з’єднання 
(join), немає складних запитів і ін. Компанія Google не поширює Bigtable, тому 
на ринку з’явилося кілька незалежно розроблених клонів цієї бази даних. 
Зокрема це такі проекти як: Hadoop, Hypertable і Cassandra [28]. 
Наступна категорія баз даних – це документо-орієнтовані бази даних. Такі 
бази нагадують Key-Value бази даних [28], але в цьому випадку в метаданих чи 
словниках бази даних вказано, що собою представляють значення. Зазвичай, 
значенням є деякий документ або об’єкт, до структури якого можна робити 
запити. Прикладами таких баз даних є CouchDB і MongoDB [28]. 
Четверта категорія – це бази даних, побудовані на графах. Такі бази 
орієнтовані на підтримку складних взаємозв’язків між об’єктами і ґрунтуються 
на теорії графів. Структура даних у таких базах являє собою набір вузлів, 
зв’язаних між собою посиланнями. При цьому й вузли, й посилання можуть мати 
деяку кількість атрибутів. Як приклад можна привести такі бази даних як: Neo4j, 
AllegroGraph, Sones graphDB [46]. 
Також існує ще й п’ята категорія, але її не відносять до NoSQL. Мова йде 
про об’єктно-орієнтовані бази даних. Такі бази даних призначені насамперед для 
підтримки об’єктно-орієнтованої парадигми програмування. Їх дуже просто 
використовувати в мовах програмування, у яких підтримується ця парадигма. 
Існує кілька механізмів для доступу до даних в NoSQL БД [30]. 
1 Restful інтерфейси. Це інтерфейс, схожий на основний протокол 
інтернету – HTTP. У рамках даного підходу передбачається, що кожний 
об’єкт, яким ми можемо маніпулювати, має свою унікальну адресу. 
18 
Звертаючись за цією адресою, ми можемо запитувати, створювати, 
редагувати або знищувати зазначений об’єкт. При цьому на сервері не 
зберігається ніякого стану, тобто кожний запит опрацьовується 
незалежно від інших запитів. 
2 Мови запитів, відмінні від SQL. GQL – SQL-подібна мова для Google 
Bigtable, SPARQL – мова запитів Семантичного Веба, Gremlin – мова 
обходу графів, Sones Graph Query Language – мова запитів до Sones 
Graph. 
3 API запити. Google Bigtable Datastore API, Neo4j Traversal API. 
 
Таблиця 1.1 
Порівняння SQL і NoSQL 
 NoSQL SQL 
Термін NoSQL охоплює Зберігаються в реляційній 
множину баз даних, кожна з моделі в рядках і 
яких може мати різні стовпцях. 
Зберігання даних 
моделі зберігання даних.  
Основні з них: документ, 
графік, ключзначення. 
Схеми являються Кожний запис відповідає 
динамічною інформацією, визначеній схемі. Схема 
яка може бути додана в може бути змінена, але в 
будь-який момент часу. цьому випадку вона 
Схеми і гнучкість 
 передбачає зміну всієї 
бази даних. Виконання 
змін відбувається 
оффлайн. 
Горизонтальна Вертикальна 
Масштабованість 
масштабованість. масштабованість. 
 
19 
Продовження таблиці 1.1 
Все залежить від Більшість реляційних баз 
технології. Багато рішень в даних відповідають ACID. 
області NoSQL не  
Відповідність ACID дотримуються 
відповідності ACID на 
користь масштабованості 
та продуктивності. 
 
NoSQL можуть запропонувати високий рівень експлуатаційної готовності, 
коректності й продуктивності.  
Головною перевагою NoSQL баз даних є продуктивність. Усі NoSQL бази 
даних перевершують реляційні бази даних у своїй ніші. Якщо ще недавно існував 
тільки один вид баз даних для всіх випадків – реляційні бази, то сьогодні ситуація 
змінилася.  
Для кожної конкретної ситуації необхідно підбирати свою модель даних. 
Іноді доводиться мати одночасно кілька баз даних, у кожної з яких 
використовуються її найсильніші сторони. Наприклад, у web-застосуваннях 
Mongodb застосовується як основне сховище даних, а за допомогою Redis 
організовується кешування запитів користувача.  
У результаті ми отримуємо систему з дуже високою продуктивністю й з 
досить зручними інтерфейсами для розроблювачів. Ще одна важлива перевага 
NoSQL баз даних полягає в тому, що багато представників цього сімейства 
сховищ даних реалізовані як проекти з відкритим кодом. 
Отже, існування різних категорій баз даних NoSQL вимагає формального 
опису моделей даних, що ними опрацьовуються. Загалом порівняння SQL і 
NoSQL подано в таблиці 1.1 [10]. 
Аналіз програмного забезпечення для роботи з Великими даними 
Концепція «Великі дані» досі не дуже добре окреслена, хоча активно 
використовується для бізнесу та технологій. Аналіз згаданих вище джерел, 
20 
науково-популярних журналів, і блогів дають змогу виділити наступні фокуси 
обговорення [18]: 
− джерела Великих даних; 
− апаратне забезпечення та інфраструктура; 
− програмне забезпечення і зберігання; 
− інформаційні технології (методи і засоби обробки даних); 
− використання Великих даних, бізнес-аналіз. 
В якості джерел Великих даних можна виділити пристрої та людей. 
Приклади перших джерел: національні та міжнародні проекти, такі як Великий 
адронний коллайдер (LHC) в ЦЕРН, Лабораторія фізики елементарних частинок 
в Європі, Великий синоптичний оглядовий телескоп на півночі Чилі; 
промисловість (SCADA, фінанси і т.д.) [21]. 
 
 
Рис. 1.3. Порівняльна характеристика OLAP та Великих даних 
 
Приклади другого типу джерел: соціальні мережі, охорона здоров’я, 
роздрібна торгівля, особисті дані про місцезнаходження, управління 
громадським сектором і т.д. 
21 
Для збору і обробки Великих даних доцільно використовувати технології 
хмарних обчислень. Хмарні обчислення – це нова парадигма для розміщення 
кластерів даних і надання різних послуг локальною мережею або через Інтернет. 
Хостинг кластерів даних дає змогу клієнтам зберігати та обчислювати величезну 
кількість даних у хмарі. 
Оскільки розмір окремих баз даних зростає швидко і подолав петабайтний 
бар’єр (наприклад, бази даних соціальних мереж), то онлайн опрацювання в 
режимі OLAP таких обсягів практично неможливе (рис. 1.2) [21]. 
 
В таблиці 1.2 [29] подано відомості щодо ряду інструментів опрацювання 
Великих даних з відкритим вихідним кодом, які надаються через інфраструктури 
хмарних обчислень. Більшість інструментів забезпечується Apache і випущені 
під ліцензією Apache [19]. Усі ці продукти згруповано за типами задач, що 
виникають в процесах опрацювання Великих даних. 
 
Таблиця 1.2 
Засоби роботи з Великими даними 
Засоби для Великих даних Опис 
Засоби аналізу даних 
Інструмент веб для надання послуг, 
Ambari http://ambari.apache.org  управління та моніторингу Apache 
Hadoop кластерів 
Avro http://avro.apache.org  Система серілізації даних 
Chukwa Система колекціонування даних для 
керування великими розподіленими 
http://incubator.apache.org/chukwa системами 
Швидкий і генеральний обчислювач 
для даних Hadoop. Забезпечує 
просту і виразну модель 
Spark http://spark.incubator.apache.org програмування, яка підтримує 
широкий спектр додатків, у тому 
числі ETL, машинного навчання, 
опрацювання потоків 
22 
Продовження таблиці 1.2 
Hive http://hive.apache.org/ Інфраструктура сховища даних, 
 яка забезпечує агрегацію даних 
Високорівнева мова потоків даних 
Pig http://pig.apache.org  і виконуваний framework для 
паралельних обчислень 
Високопродуктивна служба 
ZooKeeper http://zookeeper.apache.org/ координації для розподілених 
застосунків 
Actian Забезепечує зберігання сирих 
http://www.actian.com/aboutus/#overview даних і готує дані для подальшого 
 аналізу 
Забезпечує швидке перетвореня, 
HPCC http://hpccsystems.com  паралельне опрацювання для 
застосувань з Великимиданими 
Засоби Data Mining 
Orange http://orange.biolab.si Візуалізація та аналіз даних для 
 
новачка і експертів 
Mahout http://mahout.apache.org Бібліотека засобів машинного 
 навчання та видобування даних 
KEEL http://keel.es Еволюційний алгоритм для 
 проблем видобування даних 
Засоби соціальних мереж 
Платформа з високою пропускною 
Apache Kafka  здатністю для опрацювання даних 
в режимі реального часу 
Засоби BI 
Інтеграція даних, управління, 
Talend http://www.talend.com  інтеграція застосувань, засоби і 
сервіси для Великих даних 
Jedox http://www.jedox.com/en Функції аналізу, звітності, 
 
планування 
Pentaho http://www.pentaho.com Інтеграція даних, бізнес-аналіз, 
 візуалізація даних, прогнозування 
Rasdaman http://rasdaman.eecs.jacobs Багатовимірні расторові дані 
university.de/ (масив) без обмежень на розмір, 
 наявність мови запитів 
 
23 
Продовження таблиці 1.2 
Засоби пошуку 
Застосування для повнотекстового 
Apache Lucene http://lucene.apache.org індексування і пошуку 
Повнотекстовий пошук, фасетний 
пошук, динамічна кластеризація, 
Apache Solr http://lucene.apache.org/solr формати документів типу Word, 
PDF, просторовий пошук 
Elasticsearch Засіб розподіленого 
http://www.elasticsearch.org повнотекстового пошуку з веб-
 інтерфейсом і JSON докуметами 
MarkLogic 
http://developer.marklogic.com NоSQL і XML база даних 
 
Крос-платформенна документо-
mongoDB http://www.mongodb.org орієнтована система управління 
 
базами даних з підтримкою JSON та 
динамічних схем 
Cassandra http://cassandra.apache.org Маштабована мульти-майстерна 
 
база даних без єдиної точки відмови 
Маштабована розподілена база 
даних з підтримкою 
HBase http://hbase.apache.org  структурованого зберігання даних 
великого обсягу 
InfiniteGraph http://www.objectivity.com Розподілена графова база даних 
 
Особливості перетворення NoSQL в інші формати 
Узагальнюючи результати аналізу відображення систем баз даних NoSQL 
різних класів в інший формат, можна зробити висновок, що незалежно від класу 
системи – «ключ-значення», колонкова або документна, існує ряд cпільних 
проблем. 
Так як в NoSQL схема може бути присутня неявно, реалізованою в коді 
програми, то семантично значуще відображення в об’єктну модель автоматично 
будувати неможливо. Виявлення схеми даних для кожної окремої бази даних 
вимагатиме залучення експерта. Є сенс будувати відображення на рівні додатку 
24 
(зaстосунку), що працює над базою даних, минаючи відображення моделей 
системи баз даних. Однак ці додатки можуть бути [50]: 
− закритими для зовнішніх запитів, які не надають довільного доступу до 
даних, 
− розбитими на частини, які працюють з різними підмножинами даних з 
одних і тих же баз; 
− з однією базою може працювати багато застосунків. 
Основна причина проблем, що виникають при семантичному відображенні 
моделей даних NoSQL в об’єктну модель даних, полягає в їх слабкій 
структурованості: 
− в більшості з них не визначається схема даних в явному вигляді; 
− значення в парах «ключ-значення» часто можуть бути довільними і 
неструктурованими, ключі можуть розглядатися і як елементи 
структури, так як і дані; 
− за відсутності схеми структура пар може змінюватися динамічно; 
− фактично, за допомогою операції оновлення можна в будь-який момент 
ввести нову структуру пар «ключ-значення»; 
− бази даних зазвичай не обмежені за кількістю пар в структурах, за 
довжиною ключів, за вкладеністю пар. 
Такі системи можуть використовуватися для вирішення завдань, 
розрахованих на використання нефіксованих і необмежених 
слабоструктурованих даних (наприклад, ієрархічних або потокових).  
З іншого боку, багато програм використовують системи баз даних NoSQL 
для зберігання досить жорстко типізованих структур. І той, і інший випадки 
доводиться враховувати при відображенні в об’єктну модель. 
Під час аналізу семантики даних звертається увага на використання в 
ключах фіксованих (імена елементів структур) або нефіксованих (дані) значень. 
У разі виявлення статичної схеми даних фіксовані значення ключа 
трансформуються в атрибути типів, нефіксовані – в значення атрибутів. 
 
25 
Під час відображення створюються такі структури [82, 83]: 
− фреймові структури для вкладених пар; 
− абстрактні типи даних в разі, якщо дані підлягають виявленню чіткої 
структурі. 
Можливі різновиди запитів, які використовуються при вирішенні завдань 
над даними в моделях NoSQL повинні бути відомі заздалегідь. Дані, за якими 
необхідно організувати пошук, повинні виявитися ключами в деяких парах 
«ключ-значення», а дані, які шукають – значеннями, для чого формуються 
допоміжні пари над основними даними з відповідною структурою даних. Такі 
пари при відображенні не утворюють нові структури, а відображаються в типи і 
класи, утворені основними парами. Відповідно до допоміжних пар в цільовій 
моделі утворюються вторинні ключі. Запити з порівнянням по атрибутам, що є 
ключами в допоміжних парах, при зворотному відображенні відображаються в 
операції над цими парами [5]. 
 
1.4. Математичні методи подання Великих даних 
Багатовимірна модель даних 
Одним із способів представлення Великих даних є гіперкуб даних [10]. 
Основними поняттями багатовимірної моделі даних є: 
− гіперкуб даних rel, 
− вимір V, 
− атрибут A, 
− комірка X, 
− значення rel(V, A). 
Гіперкуб даних містить один або більше вимірів і є впорядкованим 
набором комірок. Кожна комірка визначається одним і лише одним набором 
значень вимірів – атрибутів. Комірка може містити дані – значення або бути 
порожньою. 
Під виміром у [14] розуміють множину атрибутів, що утворюють одну з 
граней гіперкуба. Прикладом часового виміру є список днів, місяців, кварталів. 
26 
Прикладом географічного виміру може бути перелік територіальних об’єктів: 
населених пунктів, районів, реґіонів, країн та ін. 
Отже, V – множина вимірів гіперкуба, AVi = {A1i ,A2i ,...,Aki } i = 1,..., n – 
множина атрибутів виміру Vi . Гіперкуб даних позначимо як множину комірок, 
що відповідає множинам V, A: rel(V, A). Підмножина гіперкуба даних, що 
відповідає множині фіксованих значень, позначається як rel(V, A). 
Кожній комірці гіперкуба даних відповідає єдино можлива множина 
атрибутів вимірів Arel. Комірка може бути порожня (не містити даних) або 
містити значення показника [10]. Множину комірок гіперкуба rel(V,A) 
позначимо як V(rel). Для отримання доступу до даних користувачу необхідно 
вказати множину необхідних вимірів і значень атрибутів (фіксувати атрибути). 
Множину комірок, що відповідають відповідним атрибутам та вимірам. 
Ключем виміру є атрибут, який однозначно визначає кортеж (рядок) 
виміру гіперкуба. Гіперкуби підтримують ієрархію вимірів і формул без 
дублювання їх визначень. Набір відповідних гіперкубів складає багатовимірну 
базу даних (або сховище даних). 
Комбінації значень вимірів визначають комірки гіперкуба. Залежно від 
конкретного застосування (прикладної програми), комірки в гіперкубі можуть 
розташовуватися як розріджено, так і щільно. Гіперкуби, як правило, стають 
розрідженими у міру збільшення числа розмірностей і ступеня деталізації 
значень вимірів. 
Багатовимірне представлення даних добре використовувати для задач 
візуалізації даних та їх аналізу, але у зв’язку з розрідженістю гіперкуба [40] обсяг 
даних у такому випадку є більший порівняно з реляційним представленням, що 
є неприпустимим до Великих даних. 
Об’єктне подання даних 
Інформація про модельовані об’єкти подається множиною складних 
значень, що зберігаються в ідентифікованих змінних (у подальшому – об’єкти 
даних). Об’єкт даних o опишемо як [30, 31] 
 
27 
{id, meta, o}, 
 
де id – унікальний ідентифікатор зазначеної змінної, meta – інформація, що 
описує структуру зазначеної змінної (метадані), де, зокрема, перелічуються 
поіменовані атрибути об’єкта даних, o – складне значення, що описує стан 
об’єкта. 
Будемо розглядати кожне зі значень ri як значення іменованого атрибута 
об’єкта о. Тоді атрибут має розглядатися як змінна відношень, а схема об’єкта 
даних повинна перелічувати імена атрибутів. Відповідно, об’єкт o буде 
описуватися як 
 
 
 
де ri – значення відношень Ri , ri = relval(Ri), Dj, – не обов’язково різні 
домени з множини D доменів. Відзначимо, що в системі O може одночасно 
існувати множина не обов’язково різних значень r того самого відношення R, що 
є значеннями атрибутів різних об’єктів або значеннями різних атрибутів того 
самого об’єкта. 
Розглянемо множину O усіх вхідних у систему об’єктів. Кожному 
об’єктові ставиться у відповідність схема об’єкта Si =oSchema(oi), що є власною 
підмножиною множини S. Та сама схема S може бути поставлена у відповідність 
багатьом об’єктам. Отже, можна стверджувати, що між множиною схем і 
множиною класів існує функціональна відповідність S= Schema(C). 
Також ми можемо говорити про існування множини R усіх визначених на 
множині доменів D відношень R, значення яких є значеннями атрибутів oai 
об’єктів із множини O. Кожному імені oa ставитися у відповідність одне і тільки 
одне відношення R з множини R, тим самим обмежуючи множину можливих 
значень атрибута з іменем oai значеннями цього відношення R. 
28 
Оскільки мова йде про пару «множина – визначене на цій множині 
значення», відношення R можна позначити як домен атрибута oa. Однак, оскільки 
значення, визначене на цьому домені, являє собою значення відношень (relval) і 
також є множиною, будемо називати відношення R реляційним доменом 
атрибута oa, R=rdom(oa).  
Отже, ми можемо говорити про функціональну відповідність між 
множиною атрибутів oa і множиною відношень R, R = rdom(oa). 
Кожне таке відображення відповідає унікальному значенню, що є 
ідентифікатором цього об’єкта. Тоді множина ідентифікованих об’єктів O – 
функціональна відповідність між множиною id, що включає унікальні 
ідентифікатори id всіх об’єктів o вхідних у множину O, і множиною відображень, 
що формують власні значення цих об’єктів. 
Припустимо, що значення унікальних ідентифікаторів об’єктів, що 
входять у множину id, визначені на домені DOID, а імена їхніх атрибутів, що 
входять у множину oa – на домені DA,Можна показати, що 
 
 
 
Звідси випливає, що 
1 об’єкт має унікальний ідентифікатор, і, отже, у системі можуть 
існувати два об’єкти з абсолютно однаковим власним значенням; 
2 значення атрибутів об’єктів є значеннями відношень, що є множиною 
кортежів – іншими словами атрибут можна розглядати як групу 
повторення. 
На рівні збереження ця ж інформація подана у вигляді множини значень 
відношень R', визначених на доменах з множини D'. Інформація про унікальні 
ідентифікатори об’єктів oi і про значення, які визначають семантику атрибутів, 
на рівні збереження існує точно в такому ж вигляді, як і інформація про власні 
значення цих об’єктів, а саме у вигляді явно заданих значень атрибутів кортежів 
29 
відношень R'. Отже, рівень збереження цілком описується в термінах реляційної 
моделі даних. З практичної точки зору цей факт цікавий тим, що він дозволяє 
реалізувати рівень збереження, використовуючи наявні реляційні СКБД. 
 
Таблиця 1.3 
Порівняння моделей представлення Великих даних 
Назва моделі Автори Переваги Недоліки 
У зв’язку з 
розрідженістю 
Добре гіперкуба з 
Багатовимірна Maté, Alejandro використовувати для неоднорідними 
модель [14] задач візуалізації даними, їх обсяг 
даних та їх аналізу. збільшується, що є 
неприпустиме до 
Великих даних 
Нерозв’язаною є 
задача 
За певної 
Chang, Fay [30], трансформації з 
Об’єктна модифікації може 
Papakonstantino, одних типів 
модель бути використана 
Y [31] представлення 
для Великих даних. 
даних в об’єктну 
модель даних 
Велика 
обчислювальна 
Добра для аналізу 
Графова складність 
Zhou Feng [32]  зв’язків між 
модель алгоритмів пошуку 
об’єктами. 
за умови великої 
кількості об’єктів 
 
30 
Множина O об’єктів o може бути однозначно перетворена до множини 
значень відношень R', що входять у множину R', причому між множиною R 
відношень, що є доменами атрибутів об’єктів o, і множиною R' існує така 
взаємно-однозначна відповідність, що для будь-якого відношення, що належить 
R, у множині R' буде існувати відповідне відношення:  
 
 
 
Тому об’єктне подання даних за певної модифікації може бути 
використане для подання інформаційних ресурсів Великих даних. Проте 
залишається нерозв’язаною задача трансформації з одних типів представлення 
даних в об’єктну модель даних. 
 
1.5. Постановка задачі дослідження 
Основними проблемами, які виникають при обробці даних, є 
відсутність методів аналізу, придатних до застосування через їх 
різнотиповість (для регіону – це і числові дані, і геодані, 
слабоструктуровані звіти тощо), потреба у значних людських ресурсах 
для підтримки процесу аналізу даних, висока обчислювальна 
складність наявних алгоритмів аналізу та стрімке зростання обсягу 
зібраних даних.  
Вони призводять до постійного зростання часу аналізу даних 
навіть при регулярному оновленні апаратних засобів серверів, а також 
– необхідність роботи із розподіленими базами даних, можливості 
яких більшість існуючих методів аналізу даних не використовують 
ефективно. 
 
31 
 
Рис. 1.4. Постановка задачі дослідження 
 
Таким чином, виникає задача розроблення ефективного методу 
аналізу даних, що може застосовуватись до розподілених баз даних 
різних предметних областей. Тому для регіону доцільно розробляти 
методи та засоби роботи з Великими даними та використання їх для 
аналізу. 
 
Висновки  
В першому розділі отримано наступні результати: 
1. Визначено складові розвитку регіону і показано, що для цього треба 
опрацьовувати різнотипні дані. 
2. Подано поняття Великих даних та описано їх характеристики. 
3. Проаналізовано інформаційні моделі представлення даних великих 
обсягів та показано їх обмеження. Це призводить до необхідності 
розроблення моделі представлення Великих даних. 
32 
4. Проаналізовано особливості NoSQL-баз даних та принципи 
перетворення даних в інші формати. Визначено нерозв’язані задачі. 
5. Проаналізовано методи прогнозування процесів територіального 
управління та окреслено їх обмеження. 
6. Здійснено постановку задачі дослідження на основі виділення раніше 
нерозв’язаних задач. 
33 
РОЗДІЛ 2 
МОДЕЛЬ ВЕЛИКИХ ДАНИХ ДЛЯ АВТОМАТИЗОВАНИХ СИСТЕМ 
УПРАВЛІННЯ 
 
 
2.1. Типи моделей даних для представлення Великих даних 
Поняття структурованих та слабоструктурованих даних 
Межу між структурованими й неструктурованими даними можна провести 
навіть інтуїтивно. Однак, перш ніж перейти до розгляду прикладів такої 
інформації і її формальних описів, пояснимо відмінність структурованої й 
слабкоструктурованої інформації докладніше. 
Модель даних – це сукупність засобів опису структур даних для додатка 
або класу додатків. Модель даних містить у собі типи й структури даних, систему 
операцій, засоби опису обмежень [15].  
Модель структурованих даних має такі особливості: по-перше, на дані 
накладаються заздалегідь відомі обмеження за типом й довжиною кожного 
атрибута, що робить ускладненим, а найчастіше навіть неможливим, 
модифікацію моделі під вимоги, що змінилися із часом; по-друге, структура 
даних відома й визначена за допомогою схеми даних, її автоматична зміна в 
процесі роботи моделі ускладнена. 
Інтерпретувати дані без знання схеми не представляється можливим. При 
цьому в процесі розробки схеми необхідно провести формалізацію 
оброблюваних даних, що унеможливлює автоматизацію коректування схеми в 
процесі використання моделі.  
Однак, внаслідок наявних обмежень, модель структурованих даних має 
великий набір можливих операцій. Прикладом реалізації моделі структурованих 
даних може виступати будь-яка реляційна система керування базою даних 
(СУБД). 
Розробка моделі для неструктурованих даних є вкрай складним завданням 
з наступних причин. По-перше, дані, як правило, представлені природньою 
34 
мовою, що ускладнює роботу з ними. По-друге, повна відсутність визначеної 
структури накладає серйозні обмеження на можливі операції з даними. 
Автоматичне виділення структури в таких даних, як правило, не може бути 
виконане однозначним чином. 
Слабоструктурованими даними є будь-які проміжні дані між 
структурованими й неструктурованими. Такі дані мають певні особливості.  
По-перше, структура даних може бути неповною, недовизначеною, а також 
допускати виключення. По-друге, значення скалярних даних представлені у 
вигляді текстової інформації. По-третє, виникає проблема визначення 
приналежності даних, тому що не завжди можна однозначно стверджувати про 
коректність опрацьованого документа. 
Модель слабоструктурованих даних повинна враховувати визначені 
особливості. Виділено основні проблеми, що виникають під час розроблення 
моделі слабоструктурованих даних.  
По-перше, при роботі з даними заздалегідь невідомий ступінь їх 
коректності, і, як наслідок, у моделі необхідний інструментарій для оцінки 
«правильності» даних. Враховуючи, що в слабоструктурованих даних усі 
атрибути представлені у вигляді текстової інформації, необхідний досить 
гнучкий механізм перевірки приналежності даних до конкретного атрибута.  
По-друге, схема даних може або зовсім не існувати, або не повною мірою 
відповідати оброблюваним даним. Оскільки працювати з документом, не маючи 
ніяких уявлень про його структуру, неможливо, виникає завдання виділення 
схеми з оброблюваних даних, а також її коректування в процесі експлуатації 
моделі й одержання нової інформації.  
По-третє, деякі атрибути даних можуть бути або взагалі відсутні, або не 
повною мірою задовольняти умовам коректності, заданим для цих атрибутів. 
Таким чином, у цій моделі повинен існувати інструмент обробки виключень, що 
дозволяє формувати спосіб запиту до цих даних, ґрунтуючись на заздалегідь 
заданих критеріях. 
35 
Існуючі методи організації зберігання й доступу до слабоструктурованої 
інформації 
Проаналізуємо три основні представлення слабоструктурованої інформації 
[8]: 
− OEM (Object Exchange Model, модель обміну об’єктами); 
− XML (Еxtensible Markup Language, розширювана мова розмітки); 
− RDF (Resource Description Framework, фреймворк опису ресурсів). 
Ці представлення, як і в науковій, так і практичній літературі даються в 
описовому, а не формалізованому виді. Як уже зазначалось в попередньому 
параграфі, під слабоструктурованими даними розуміють такі дані, які протягом 
невеликого проміжку часу можуть виявитися недостатньо формалізованими, 
неповними, або мати структуру, яка може значно змінитися.  
Як правило, такі дані не можуть бути описані за допомогою якої-небудь 
незмінної схеми, тому іноді їх називають schema-less (такі, що не мають схеми), 
а також self-describing (самоописуваними). 
Характерною рисою слабоструктурованих даних є те, що описова 
інформація, яка зазвичай виділяється в окрему схему, є присутньою у самих 
даних. Досить докладно існуючі методи організації зберігання й доступу до 
слабоструктурованої інформації розглядалися у роботі [15], а нижче будуть 
запропоновані формальні моделі для найпоширеніших методів подання 
слабоструктурованих даних. 
Слабоструктурована інформація в OEM-поданні 
У рамках OEM-подання [33] – моделі, розробленої раніше всіх інших, 
поняття слабоструктурованих даних означає скоріше не той факт, що дані не 
можуть мати певну структуру, а те, що схема даних піддається доволі частій зміні 
за кількістю і типом атрибутів сутностей і зв’язків між ними. На етапі розробки 
OEM-схеми даних, у принципі, немає перешкод для реалізації в реляційних 
таблицях набагато більшого числа атрибутів даних, аніж потрібно практично, 
тобто на «майбутнє» їх застосування. Найчастіше при проектуванні схеми даних 
36 
розробники діють саме таким чином, надалі одержуючи громіздку й надлишкову 
структуру зберігання, що не піддається адекватному формалізованому опису. 
Перерахуємо основні ознаки OЕМ-подання, що приводять до появи 
слабкої структурованості БД. 
1 Дані потрапляють в базу з гетерогенних джерел. Вони можуть містити 
пропуски, або дублювання, або мати вкладеність різної глибини. 
2 Схема даних може мінятися залежно від семантичної інтерпретації 
збережених даних. Наприклад, схема даних змінюється залежно від 
підходу до складання колекції неформатованих текстових документів, 
присвячених деякій тематиці. 
3 Схема даних постійно ускладнюється й вимагає деталізації. Наприклад, 
часто змінюються умови зовнішнього середовища, граничні значення 
показників, склад базових і нормативних характеристик, що 
зберігаються в БД. 
4 Схема даних повинна надходити разом із запитами даних, тобто бути 
вбудованою. Наприклад, різні рівні доступу до конфіденційної 
інформації не повинні виявляти й розкривати цілком усю структуру БД. 
Першим відомим дослідницьким проектом, що практично 
використовуєOEM-подання й спрямований на інтеграцію структурованих даних 
(представлених реляційними БД), слабоструктурованих даних (зокрема, 
xmlсторінок) і неструктурованих даних (колекцій файлів текстів) є проект 
TSJMMIS [42]. 
Архітектура компонентів у зазначеному проекті наступна: 
1 транслятори/конвертори даних; 
2 медіатори; 
3 менеджери обмежень; 
4 класифікатори/екстрактори даних. 
Перший компонент призначений для конвертування даних, що надходять 
із різних джерел до формату єдиної інформаційної моделі проекту TSIMMIS. 
Другий компонент, медіатори, являють собою інформаційні роутери 
37 
інформаційних запитів, що перенаправляють дані окремим трансляторам, а 
також об’єднують результати вибірок даних. Третій компонент, менеджери 
обмежень, виконують перевірку несуперечності й відповідності вихідної 
інформації вхідному запиту. Четвертий компонент, класифікатори/екстрактори 
даних необхідні для добування ключових характеристик зі слабоструктурованих 
(неструктурованих) джерел даних і виділення в них деякого «резюме», тобто 
деякої системної складової, відповідно до якої їх можна було б віднести до того, 
або до іншого класу. Обмін інформацією в проекті TSIMMIS здійснюється за 
допомогою самоописової моделі даних OEM. 
Цей проект був неповністю автоматичною системою зберігання й обробки 
даних, у зв’язку із чим користувачі взаємодіяли з нею за допомогою інтерфейсу 
MOBIE (Mosaic Based Information Explorer), могли переглядати OEM - об’єкти й 
виконувати запити до даних на SQL- подібній мові – OEM-QL. 
Слабоструктурована інформація в XML-представленні 
Умовам schema-less і self-describing насамперед відповідає XML- подання 
слабоструктурованих даних. Мова XML є підмножиною мови SGML (Standard 
Generalized Markup Language, стандартна узагальнена мова розмітки). SGML 
являє собою систему визначення структурованих типів документів і мов 
розмітки екземплярів документів таких типів. Ця мова дозволяє розділити 
будьякий документ на дві логічно незалежні частини; одна з них визначає 
структуру документа, а інша містить сам текст. Визначення структури 
називається визначенням типу документа (Document Type Definition – DTD). 
Мова SGML уможливлює призначення для будь-якого документа окремо певну 
структуру й дає можливість авторам документів створювати власні, 
спеціалізовані структури, тому може стати основою надзвичайно потужної 
системи керування документами. Проте, ця мова відрізняється значною 
складністю, тому не одержала досить широкого поширення. 
Мова XML призначена для виконання аналогічних функцій, але є менш 
складною і разом з тим більше пристосована для використання в мережі. При 
цьому дуже важливо те, що мова XML зберегла основні переваги SGML, 
38 
розширюваність, структурованість і можливість перевірки правильності 
документів. Оскільки XML є підмножиною SGML, то будь-яка система, 
повністю сумісна з SGML, має здатність обробляти документи XML (але 
зворотне твердження не є дійсним). Проте мова XML не призначена для заміни 
SGML. До того ж вона не може замінити мови HTML, яка також заснована на 
SGML і є додатком цієї мови. У дійсності, XML призначена для використання як 
доповнення до мови HTML і повинна забезпечити передачу через WWW даних 
різних типів. Завдяки своїм широким можливостям мова XML фактично може 
застосовуватися не тільки для розмітки тексту, але й для розмітки звуку або 
зображення, тобто мультимедійних даних. У якості прикладів широко 
застосовуваних мов, створених на основі XML, можна вказати Mathml 
(Mathematics Markup Language – мова математичної розмітки), SMIL 
(Synchronized Multimedia Integration Language – мова інтеграції синхронізованих 
джерел мультимедійної інформації) і CML (Chemistry Markup Language – мова 
хімічної розмітки). 
Мова XML уже фактично стала стандартним засобом обміну даними в 
індустрії програмного забезпечення. Деякі аналітики припускають, що згодом 
мовою XML буде створюватися й зберігатися більшість документів як в 
Інтернеті, так і за його межами. Не дивлячись на все це, сама по собі мова не є 
моделлю даних, оскільки надає тільки можливості зберігання інформації, і не має 
інструментів маніпуляції даними, інструментів опису обмежень, способів опису 
схеми. 
Для того щоб використовувати XML як повноцінну модель були 
розроблені наступні рішення. По-перше, мова опису структури XSD (XML 
Schema Definition), що дозволяє описувати схеми даних XML документа. XML 
Schema описує спосіб визначення в схемі елемента кожного типу й дає змогу 
вказати типи даних, пов’язані з кожним елементом. Схема сама є документом 
XML, у якому використовуються елементи й атрибути, що виражають семантику 
схеми. А оскільки схема – документ XML, то її можна редагувати й обробляти за 
допомогою таких же інструментальних засобів, які застосовуються для обробки 
39 
описаного нею документа XML. Один з найпростіших способів створення схеми 
XML полягає у відстеженні структури документа й визначенні кожного елемента 
в міру виявлення.  
Елементи, що містять інші елементи, відносяться до типу складних 
елементів. По-друге, штучна мова DTD (Document Type Definition), що надає 
можливість створення обмежень і вимог до XML документу та його атрибутів. І 
нарешті, мови запитів, такі як xpath і xquery, що дозволяють оперувати даними. 
Методи, засновані на XML моделі, не вирішують багато проблем, зв’язаних зі 
слабоструктурованими даними, тому що не мають необхідного інструментарію 
відновлення структури документа й засобів опрацювання виникаючих 
невідповідностей оброблюваних даних до очікуваної структури. 
Очевидно, що специфікація XML Schema надає повніший і строгіший 
метод визначення моделі інформаційного наповнення документа XML, аніж 
визначення DTD. Але вона все-таки не забезпечує підтримку необхідного рівня 
семантичної функціональної сумісності.  
Наприклад, якщо два додатки повинні обмінюватися інформацією за 
допомогою XML, то призначення і зміст застосовуваних при цьому документів 
повинні бути погоджені з тою структурою даних, яка ними формується. Але для 
цього необхідно сформувати модель предметної області з описом даних, які 
потрібні для того чи іншого додатка. Це дозволяє чітко визначити, які дані 
повинні передаватися в прямому й зворотному напрямках від одного додатка до 
іншого. Таку модель зазвичай прийнято описувати в термінах об’єктів або 
відношень. А оскільки схема XML описує тільки синтаксичну структуру 
документа, то сама модель предметної області може бути представлена у вигляді 
схеми XML багатьма різними способами. Тому неможливо визначити 
безпосередню відповідність між моделлю предметної області й певною схемою 
[10]. Ця проблема стає ще складнішою, якщо в обміні інформацією повинні брати 
участь не два, а кілька додатків. У такому випадку недостатньо просто 
встановити відповідність між декількома схемами XML, оскільки завдання тут 
полягає не у перетворенні однієї синтаксичної структури в іншу, а у встановленні 
40 
відповідності між об’єктами й відношеннями, що належать до декількох 
предметних областей. 
Таким чином, для розв’язання описаної вище задачі необхідно виконати 
три етапи: 
1 відновити первісні моделі предметних областей зі схем XML; 
2 визначити відповідності між об’єктами моделей предметних областей; 
3 визначити механізми перетворення для документів XML, наприклад, за 
допомогою мови XSLT (Еxtensible Stylesheet Language 
Transformations). 
Ці етапи на практиці іноді стають дуже складними, тому може виявитися, 
що мова XML добре підходить для обміну даними тільки між додатками, для 
яких уже відома модель інформаційного наповнення, але погано підходить для 
тих ситуацій, коли до обміну даними приєднуються все нові й нові додатки. 
Доступ до слабоструктурованої інформації в XML- представленні  
Можна виділити такі методи й мови доступу: Xpath (XML Path), Xlink 
(XML Linking); Xpointer (XML Pointer). 
Xpath – це декларативна мова запитів для XML, у якій передбачені прості 
синтаксичні конструкції для адресації окремих частин документа [13]. У мові 
Xpath визначено 13 типів осей (обов’язкових частин), включаючи ancestor 
(предок), attribute (атрибут) і child (нащадок). Предикат повинен бути укладений 
у квадратні дужки й знаходитись після базису. Якщо елемент містить більше 
одного субелемента, для вибірки конкретного субелемента може 
застосовуватися конструкція [position{)= ’positionnumber’], де positionnumber – 
номер позиції, що починається з 1. У мові Xpath підтримується повний і 
скорочений синтаксис. 
Мова Xlink дозволяє вставляти в документи спеціальні елементи, за 
допомогою яких можна створювати й описувати посилання між ресурсами [12]. 
У ній застосовується синтаксис XML для створення структур, що дозволяють 
описувати посилання, аналогічні простим, односпрямованим гіперпосиланням 
HTML, а також складніші посилання. Посилання Xlink можуть ставитися до 
41 
одного із двох типів: простого і розширеного. Просте посилання з’єднує джерело 
з ресурсом призначення, а розширене посилання з’єднує будьяку кількість 
ресурсів. Крім того, ця мова надає можливість зберігати посилання в окремій БД 
(її називають базою посилань Unkbase). Тим самим надається можливість 
домогтися в деякій мірі незалежності від місцезнаходження ресурсів: навіть у 
випадку зміни посилань вихідні документи XML залишаються незмінними, і 
відновлення вносяться тільки в базу посилань. 
Мова Xpointer надає доступ до значень атрибутів або до вмісту елементів, 
що перебувають у будь якому місці документа [14]. Будь-який покажчик 
Xpointer, за суттю, являє собою вираз Xpath, що входить в ідентифікатор URІ. 
Крім усього іншого, мова Xpointer дозволяє сформувати посилання на 
розділи тексту, вибрати конкретні елементи або атрибути й перейти з одного 
елемента на інший. Ця мова дає можливість також здійснити вибірку інформації, 
що знаходиться більше ніж в одному наборі вузлів, тоді як за допомогою мови 
Xpath це завдання виконати неможливо. Крім визначення вузлів, у мові Xpointer 
визначаються також точки й діапазони, які в комбінації з вузлами дозволяють 
позначити місцезнаходження даних. Точка – це позиція в документі XML, а 
діапазон позначає всю структуру й інформаційне наповнення XML між 
початковою й кінцевою точками, причому й та, і інша можуть перебувати в 
середині вузла. 
Слабоструктурована інформація в RDF-представленні 
Інфраструктура опису ресурсів (Resource Description Framework - RDF), 
розроблена під егідою W3C, являє собою інформаційне середовище, яке 
забезпечує кодування, обмін і повторне застосування структурованих метаданих 
[101]. Ця інфраструктура забезпечує функціональну сумісність метаданих різних 
додатків за рахунок застосування таких проектних механізмів, які дозволяють 
створювати загальноприйняті угоди по семантиці, синтаксисі й структурі 
документів. Інфраструктура RDF не визначає семантику кожної розглянутої 
предметної області, а надає можливість створювати в міру необхідності 
елементи метаданих для таких предметних областей. В інфраструктурі RDF у 
42 
якості загального синтаксису для обміну й обробки метаданих застосовується 
мова XML. За допомогою засобів мови XML створюються моделі даних RDF, 
структура яких забезпечує опис семантики, а також дозволяє створювати 
однаковий опис і забезпечувати обмін стандартизованими метаданими. 
Найпростіша модель даних RDF складається із трьох об’єктів. 
1 Ресурс. Ресурсом є все, що може мати ідентифікатор URL, наприклад, 
Web-сторінка, ряд Web-сторінок або навіть частина Web-сторінки, така 
як елемент XML. 
2 Властивість. Це – конкретний атрибут, який служить для опису 
ресурсу. Наприклад, атрибут Author може використовуватися для 
опису особи, що підготувала конкретний документ XML. 
3 Оператор. Це – конструкція, що складається з комбінації ресурсу, 
властивості й значення. Компоненти оператора RDF прийнято називати 
«суб’єктом», «предикатом» і «об’єктом». 
Схема RDF дозволяє представити інформацію про класи, що входять у 
схему, у тому числі про їхні властивості (атрибути) і про зв’язки між ресурсами 
(класами). Інакше кажучи, механізм визначення схеми RDF надає базову систему 
типів для використання в моделях RDF, аналогічно схемі XML. 
Схеми RDF надають також можливість визначити деяку частину 
обмежень, зокрема вказати необхідну кардинальність і визначити припустимі 
властивості екземплярів класів. Для визначення схеми RDF застосовується 
декларативна мова, створена під впливом ідей з області представлення знань 
(наприклад, семантичних мереж і логіки предикатів), а також моделей 
представлення схем БД, таких як двійкові реляційні моделі й моделі даних на 
основі графів. 
Слабоструктурована інформація в документо-орієнтованому 
представленні 
Грунтовний виклад методів документо-орієнтованого зберігання подано в 
роботі [27]. В основі цих методів лежать колекції даних, тобто набори, у яких 
збираються однотипові за деякими ознаками документи. Колекції призначені для 
43 
узагальнення однотипних документів, підтримки схем даних документа й 
забезпечення підтримки групових операцій над документами. Для кожної 
колекції може бути визначена своя схема даних, свій пошуковий індекс і 
додаткова інформація про мітки. Якщо проводити паралель із реляційними 
моделями даних, то колекція – це аналог кортежів (таблиць), з єдиною 
відмінністю, що про зв’язки між колекціями мова навіть не йде. Документ сам 
по собі представляє одиницю зберігання даних і кожний з них не залежить від 
інших. При роботі зі слабоструктурованими даними тип подання інформації 
може мінятися від документа до документа в рамках однієї колекції. Це показує 
ступінь відмінності з реляційними моделями, де тип видачі інформації із БД 
визначається заздалегідь, при проектуванні схеми даних. 
Для ідентифікації документів кожному документу присвоюється 
універсальний ідентифікатор. У якості ідентифікатора можна використовувати 
рядок, що має достатню складність і довжину для забезпечення унікальності. 
Найкращим варіантом вважається застосування хеш-функцій MD5. Над 
документами в колекції визначені такі операції: 
1 Додавання нового документа. Головна особливість операції додавання 
полягає в тому, що знання схеми даних для даної операції не потрібно, 
більше того, колекції в момент вставки документа може не існувати. У 
момент вставки, модель повинна перевірити документ, що додається, 
скорегувати або створити схему даних, і повинна зберегти дані про 
операцію для подальшої статистичної обробки. 
2 Відновлення документа. Вона визначена тільки цілком для документа. 
Таке штучне обмеження дозволить перенести контроль атомарності на 
рівень цілого документа. Відсутнє поняття «ізоляції». Будь-які дані, які 
зчитуються одним користувачем, можуть паралельно змінюватися 
іншим клієнтом. За рахунок відсутності механізму блокувань і 
контролю цілісності даних виходить збільшення швидкості роботи БД. 
3 Операція видалення документа. Операція може бути виконана тільки за 
будь-якою пошуковою умовою. 
44 
Документи мають значення елементи-атрибути. З них формується весь 
документ, і вони, за суттю, є найменшою одиницею даних, якою можна 
оперувати за допомогою документо-орієнтованої моделі. На відміну від 
класичних реляційних моделей атрибути не мають строгої типізації, тому що 
оброблювані дані не мають явно вираженої структури. Наприклад, той самий 
атрибут у різних документах однієї колекції може бути представлений як 
текстом, так і числом. Значення в атрибутах не мають обмежень на довжину й 
можуть бути змінені тільки спільно з усім документом; таким чином, операція 
відновлення (зміни) вмісту одного атрибута не визначена. Для контролю 
коректності даних, що вводяться, визначені спеціальні функції-валідатори, що 
беруть на себе завдання з контролю обмежень, наявних для атрибутів. 
Функції-валідатори призначені для організації гнучкої типізації даних у 
БД, тому що слабоструктуровані дані найчастіше представлені неформальною 
мовою, у зв’язку із чим виникає завдання визначення типів даних. При цьому 
найчастіше неможливо однозначно визначити тип даних атрибута, тому 
завдання його розпізнавання перебирають на себе зазначені функції, що 
аналізують зміст атрибута та повідомляють наскільки (якою мірою) даний 
атрибут відповідає шуканому типу даних. 
Елементи реалізації ідеї слабоструктурованої обробки й зберігання даних 
є в безсхемних БД, що відносяться до типу NoSQL(Not Only SQL, не тільки SQL) 
[28] систем. Їхньою особливістю, зокрема, є горизонтальне масштабування, 
сховища даних та підтримка пошуку й індексування по довільних полях, а в 
деяких БД є можливість формування будь-яких запитів вибірки даних. 
Найпростішим способом реалізації слабоструктурованого зберігання 
даних є динамічне сховище ключів і значень, яке реалізовано в БД Redis і Riak. 
Іншим підходом до забезпечення можливості динамічної зміни структури БД є 
стовпчикова реалізація зберігання даних (протилежно до рядкової в реляційних 
БД), при якій є можливість визначення різної кількості стовпців для різних 
рядків. За таким принципом влаштовані БД Hbase, Cassandra, Hypertable. 
45 
До таких, зокрема, відносять БД Mongodb, Couchdb. У БД Mongodb 
документ буде ставитися й зберігатися в якій-небудь колекції, а форматом 
зберігання служить структура мовою JSON. Схема БД Mongodb повністю 
змінювана, використовує технологію Google Mapreduce, що допускає побудову 
широкого спектра індексів документів: унікальних, складних, геопросторових і 
вкладених. Для стійкості й надійності зберігання даних застосовується 
атомарність операцій, журналювання, технологія асинхронної реплікації із 
сегментацією по декількох наборах реплік. Безсхемна БД Couchdb також 
використовує масово-облікові функції тарreduce, інтерфейс REST API для 
безпосередньої обробки вилучених даних через HTTP протокол, а також формат 
опису даних JSON. 
 
 
Рис. 2.1. Співвідношення структурованої й слабкоструктурованої інформації в 
Digital Universe 
 
Поряд із привабливими можливостями документо-орієнтованого 
зберігання даних є й особливості, які не дуже приймають розробники 
автоматизованих систем на основі БД. Серед таких: відсутність транзакцій, 
неможливість автоматичного приведення типів даних, ускладнена робота з 
46 
масивами даних у відношенні їх сортування й фільтрації, вимога приведення 
даних до певного формату й відсутність інших звичних функцій БД. 
Великі обсяги даних вимагають нових підходів і методів добування знань 
і даних з них. У зв’язку з тим, основні наукові положення пов’язані з розробкою 
графових моделей зберігання слабоструктурованої і нечіткої інформації. 
Подальші положення стосуються цих методів і їх реалізацій. Тому необхідно 
виконати докладний аналіз місця графових моделей даних у сучасних 
аналітичних системах і платформах [16]. 
 
 
Рис. 2.2. Співвідношення мультиструктурних моделей даних і реляційних 
моделей 
 
За оцінками інформаційно-аналітичної компанії IDC (International Data 
Corporation) обсяги «цифрового всесвіту» (Digital Universe) [66] до 2023 року 
можуть досягти 40 зеттабайт, тобто 40 трильйонів гігабайтів, з яких до 80% буде 
становити так звана погано-, слабоструктурована інформація, що циркулює у 
вигляді інтервальних медіа-потоків, інформації соціальних мереж, медіа-мереж, 
мережних мобільних пристроїв і так далі. Графічна ілюстрація, за даними IDC, 
наведена на рис. 2.1, показує співвідношення структурованої й 
слабоструктурованої інформації в сучасній Digital Universe. 
47 
Превалювання слабоструктурованих даних над структурованими, як і 
мультиструктурної моделі даних над реляційною моделлю, відзначається й в 
аналітичних матеріалах досліджень ІТ-ринку компанією Gognizanl, рис. 2.2. 
Основними постачальниками, оброблювачами й сховищами даних у 
сучасній Digital Universe є розподілені мережні системи й пристрої різного 
призначення. 
 
2.2. Формальний опис структури Великих даних 
Яскравим прикладом Великих даних є масив даних, що описує 
функціонування: 
− обсяги інформації у петабайтах; 
− необхідність обробки структурованої та неструктурованої інформації; 
− он-лайн аналіз даних для швидкого доступу до детальних даних. 
Отже, у підсумку існує: 
− великий набір сутностей: особи, місця, організації (фізичні, юридичні), 
дати, природні ресурси (річки, ліси, озера), рекреаційний фонд 
(історичні пам’ятки, санаторії), законодавчі акти та звіти; 
− величезна база даних особливостей: документи для інтелектуального 
аналізу даних, онтологічні терміни, словники даних, які дозволяють 
зв’язати деякі об’єкти. 
У подібних ситуаціях, коли у нас є кілька сутностей, пов’язаних з 
харакетристикою, використаємо кількісне представлення інформації, тобто 
кількість бінарних запитань (так, ні), які необхідно задати, щоб знайти потрібний 
об’єкт. Загалом, якщо ми знаємо, що невідомий об’єкт належить множині, що 
складається з N елементів, то ми можемо розділити цей набір на дві половини і, 
задаючи двійкові питання, з’ясувати, до якої половини належить шуканий 
об’єкт. Отже, тоді кількість об’єктів становитиме N/2. Продовжимо далі таку ж 
процедуру: задамо друге питання, для чого поділимо виділену половину ще на 
дві половини. Отже, після двох запитань матимемо N/4 об’єктів, серед яких є 
шуканий. Після трьох запитань матимемо N/8. Загалом, після відповіді на q 
48 
бінарних запитань матимемо множину з 2 -q елементів, що містить необхідний 
об’єкт [12]. 
Таким чином, той факт, що сутність пов’язана з характеристикою f, 
дозволяє зменшити кількість питань до 
 
 
 
Крім того, ефект кількох асоціацій може бути описаний шляхом 
підрахунку кількості додаткових бінарних питань, які ми можемо задавати, щоб 
і надалі знати асоціацію з необхідною сутністю. Кожне бінарне запитання 
зменшує кількість об’єктів на половину; q питань зменшують кількість до n.  
Для кожної сутності e маємо кількість питань I(e, f) для різних 
характеристик f . Значення важливості необхідно нормалізувати: 
 
 
 
Ця відстань залежить від кількості характеристик: наприклад, якщо на 
додаток до документів, ми зберігаємо їх копії, відстань збільшується вдвічі. Щоб 
уникнути цієї залежності, відстань d(e1,e2), як правило, нормалізується в 
інтервалі [0,1] через ділення на максимально можливе значення цієї відстані. 
На рис. 2.3 показано використання моделі «сутність-характеристика» для 
порівняння схем даних реляційної бази даних та NoSQL бази даних. У першу 
чергу визначається, у скількох джерелах характеристики асоціюються з 
вказаними сутностями. Далі ця інформація може бути використана для 
49 
порівняння схем за сутностями. Введемо поняття моделі асоціацій між об’єктами 
та характеристиками для різних категорій NoSQL баз даних. 
 
 
Рис. 2.3. Порівняння схеми реляційної бази даних та NoSQL бази даних з 
допомогою моделі «сутність-характеристика» 
50 
2.3. Моделі асоціацій між сутностями та характеристиками для різних 
категорій NoSQL баз даних 
Для версійного розподіленого зберігання великих обсягів даних 
спроектована модель, що використовується у системі BigTable компанії Google: 
− неповна реляційна модель даних; 
− підтримка динамічного контролю над розміщенням даних. 
У базі пошукача іменами рядків можуть слугувати адреси документів з 
інтернету, а іменами стовпців – особливості цих документів (наприклад, зміст 
документа може зберігатися в стовпці «content:», а посилання на дочірні сторінки 
– в шпальтах «anchor:»). Інший приклад – карти Google, що складаються з 
мільярдів зображень, кожне з яких деталізує ту чи іншу географічну ділянку 
планети. У Bigtable карти Google структуруються таким чином: кожному рядку 
відповідає один географічний сегмент, а стовпцями є зображення, з яких цей 
сегмент складається, у різних стовпчиках зберігаються зображення з різною 
деталізацією. 
Рядки Bigtable (їх максимальна довжина може досягати 64 кілобайти) теж 
важливі. Операція звернення до рядка є атомарною (це означає, що, поки одна 
програма звертається до рядка, жодна інша не має права змінювати дані в 
сімействах стовпців цього рядка). А ще рядки зручно сортувати. У прикладі з 
URL документа, зробивши його запис реверсивним, легко впорядкувати всі 
рядки за іменем домена третього рівня. 
Вміст сторінок в інтернеті постійно змінюється. Щоб врахувати ці зміни, 
кожній копії даних, що зберігаються в стовпці, присвоюється тимчасова мітка 
(timestamp). У Bigtable тимчасовою міткою слугує 64-розрядне число, яке може 
кодувати час і дату так, як це потрібно клієнтським програмам. Наприклад, 
timestamp для копій веб-сторінки в стовпці «contents:» є датою і часом створення 
цих копій. Використовуючи тимчасові мітки, додатки можуть задати в Bigtable 
пошук, наприклад, тільки найостанніших копій даних. 
Отже, для предметної області будь-якого сервісу Google можна створити 
власну карту даних Bigtable, що містить довільне число рядків і унікальний для 
51 
цієї предметної області набір сімейств стовпців. Неминучі повтори даних у 
стовпцях упорядковуються за тимчасовими мітками. Усе це вказує на повну 
відсутність підтримки властивостей ACID. 
Але головною перевагою цього підходу є те, що таку базу неважко порізати 
на незалежні шматочки і розподілити на множині серверів. Відсортовані за 
алфавітом рядки діляться на діапазони, які іменуються «Таблет» (tablet) – 
несамостійними таблицями. Оскільки рядки в кожному Таблеті відсортовані за 
ключовим іменем, то клієнтським додаткам дуже просто знайти потрібний 
таблет, а в ньому – потрібний рядок. 
В цій моделі ключ ідентифікує рядок, який містить дані, що зберігаються 
в одному чи декількох сімействах стовпчиків. В рамках таких сімейств кожен 
рядок може мати багато значень стовпчиків. Значення в кожному стовпці містять 
мітку часу, тому декілька значень-відповідностей між рядком і стовпчиком 
можуть знаходитися в рамках одного сімейства стовпчиків. 
Bigtable – це велика і розподілена система для об’єктів, що 
синхронізуються, тому замість них застосовується розподілений сервіс 
блокувань (distributed lock service), який в Google називають Chubby. Його роль 
в Bigtable можна порівняти з роллю транзакцій в звичайних СУБД [27]. 
Для кожного таблет-сервера Chubby створює спеціальний chubby-файл. 
Завдяки цьому файлу Bigtable Master завжди відомо, які з серверів працездатні. 
Ще один chubby-файл містить посилання на розташування кореневого таблета 
(Root-tablet) з даними про розташування всіх інших таблетів. Цей файл 
повідомляє майстру, який з серверів якими таблетами керує. 
Безумовно, використання сервісу Chubby в Bigtable якоюсь мірою вирішує 
завдання підтримки несуперечливості даних у розподіленому середовищі з 
безліччю реплік. Але несуперечливість буває різною. Bigtable стала першою 
спробою досягти балансу між продуктивністю системи, її масштабованістю і 
несуперечливістю даних. Результатом стала підтримка так званої слабкої 
несуперечливості, яка, в принципі, задовольняє вимоги більшості працюючих з 
Bigtable сервісів. На рис. 2.4 показано, як користувач шукає свій таблет [18]. 
52 
 
Рис. 2.4. Ієрархія таблетів 
 
Структура XML-документа, що складається з вкладених елементів-тегів 
добре відома, її відмінність від розглянутої вище графової моделі полягає, в 
основному, у трактуванні тегів і міток: в графах мітки використовуються як 
позначення зв’язків між елементами схем даних, і мітки не потрібні для 
позначення елемента, а в XML документно-орієнтованій моделі потрібно, щоб 
кожний (нетекстовий) елемент даних мав ідентифікуючу ознаку. Також XML 
транслюється в структуру даних «дерево», що є частковим випадком графової 
моделі. 
У графовій моделі XML для слабоструктурованих даних необхідно 
використовувати спеціалізовані типи атрибутів, такі як ID, IDREF, IDREFS. 
Зазначені типи дають змогу організувати зберігання перехресних посилань в 
XML-елементах виду <eid,vahie> (<ідентифікатор елемента, значення>) і 
атрибутах виду < label, eid> (<мітка, значення>). 
Існує кілька видів RDF-даних як графової моделі: RDF / XML, N3, Turtle, 
RDF / JSON. Опис ресурсів у вигляді RDF-набору даних – це трійка «суб’єкт»-
«предикат»-«об’єкт», тобто для множини U (Universal Resource Identifier, URI, 
уніфікований ідентифікатор ресурсів) – елементи f, множини В {Black nodes, 
порожніх вузлів), множини L {Literal, RDF-літералів), визначається набір (f, e(f), 
e), де f – «суб’єкт»; e(f) – «предикат»; e – «об’єкт». 
53 
Отже, Великі дані поєднують різні моделі даних. Для цього повинні 
існувати методи їх перетворення з мінімальною втратою даних. Однією з 
технологій, що доцільно використовувати для роботи з Великими даними, є 
простір даних. 
 
Висновки  
Удругому розділі отримано наступні результати: 
1. У розділі побудовано модель даних «сутність-характеристика» для 
Великих даних, що дає змогу опрацьовувати дані різних форматів. 
2. Для аналітичного опрацювання Великих даних використано сховище 
даних, що дає змогу працювати з Великими даними без проміжного 
збереження і тим самим зменшує обчислювальну та ємнісну складність 
виконання запитів. 
3. Визначено моделі асоціацій об’єктів та характеристик основних 
представлень даних в NoSQL. Побудовано інформаційну структуру 
Великих даних. Усе це стало основою для продовження досліджень і 
зосередженню на проблемі опрацювання різнорідних даних без їх 
попередньої інтеграції. 
4. Для представлення Великих даних використано простір даних, який дає 
змогу працювати з різнотипними даними. Проте основною операцією 
інтеграції даних є не консолідація, що дає змогу зменшувати ємнісну 
складність запитів. 
 
54 
РОЗДІЛ 3 
УДОСКОНАЛЕННЯ МЕТОДУ АНАЛІЗУ ДАНИХ В МОДЕЛІ 
«СУТНІСТЬ-ХАРАКТЕРИСТИКА» 
 
 
3.1. Використання простору даних для моделювання Великих даних 
Оскільки для формування асоціацій між сутностями та характеристиками 
необхідно працювати з різними джерелами даних, в яких один і той самий об’єкт 
може бути представлений під різними назвами, то для порівняння схем джерел 
даних доцільно використовувати простір даних з каталогом даних та словником 
даних для порівняння назв об’єктів. 
Простір даних – це блоковий вектор, що містить множину інформаційних 
продуктів предметної області, поділену на три блоки: структуровані дані (бази 
даних, сховища даних), напівструктуровані дані (XML, електронні таблиці) та 
неструктуровані дані (текст). Над цим вектором та його окремими елементами 
визначено операції та предикати, які забезпечують [3]: 
− перетворення різних елементів вектора один в одного; 
− об’єднання елементів одного типу; 
− пошук в елементах за ключовим словом. 
Моделі даних джерел, що можуть бути частиною Великих даних, 
утворюють ієрархію відповідно до їх виразної потужності [31]: 
− реляційна модель; 
− багатовимірна модель; 
− об’єктно-реляційна модель; 
− об’єктно-документна модель; 
− розширена мова розмітки інформації (XML) зі схемою; 
− середовище описання ресурсів (Resource Description Framework – RDF), 
− стандартний засіб описання зв’язків між об’єктами даних – онтології, 
описані за допомогою Web Ontology Language – OWL;  
55 
− структурований текст (у тому числі HTML, Excel); 
− слабоструктурований текст. 
Придатність моделей даних до підтримання мов запитів та до 
використання в глобальній мережі подано на рис. 3.1 [30]. 
 
 
Рис. 3.1. Придатність моделей даних до підтримання мов запитів та до 
використання в глобальній мережі 
 
Кожен учасник простору даних підтримує деяку модель даних і деяку мову 
запитів, відповідну цій моделі. Запит до такого програмного засобу відповідає 
тому, що зазвичай підтримується у файлових системах стосовно до їх 
директорій: зіставлення імен, пошук в діапазоні дат, сортування за розміром 
файлу та ін. На наступному рівні простору даних модель даних повинна 
підтримувати мультимножини слів з метою здійснення ефективного пошуку 
56 
необхідної інформації за ключовими словами. Нижче рівня моделі 
мультимножини слів в ієрархії може розташовуватися модель 
напівструктурованих даних, заснована на позначених графах. Оскільки джерела 
даних є різнотипні, то необхідно визначити платформу та архітектуру ПД. 
Платформа підтримання ПД (ПППД) – це набір програмного забезпечення, 
що керує організацією, зберіганням і пошуком даних у просторі. Також здійснює 
контроль безпеки та цілісності. 
 
 
Рис. 3.2. Рівні реалізації фізичної моделі простору даних 
57 
Архітектуру простору даних спроектовано за рівнями (рис. 3.2). Рівень 
застосувань призначений для реалізації операцій над даними у просторі даних. 
Рівень онтологій використовується для встановлення зв’язку між джерелами. 
Останній рівень містить джерела даних та забезпечує доступ до даних та 
виконання операцій рівня застосувань безпосередньо в джерелі (наприклад, 
операція вибірки на рівні реалізації виконується як запит в конкретній базі 
даних). 
Формалізація каталогу простору даних 
Каталог Cg – це реєстр ресурсів даних, що містить базову інформацію про 
кожного з них: джерело, ім’я, місцезнаходження в джерелі, розмір, дату 
створення і власника, технологічну платформу, протоколи та режим доступу, 
частоту оновлення та ін.  
Він не лише містить описову інформацію (тобто виконує роль метаданих), 
але й зберігає для кожного учасника схему джерела, статистичні дані, швидкість 
зміни, точність, можливості відповідей на запити, інформацію про власника і 
дані, про політику доступу і підтримання конфіденційності. 
 
 
Рис. 3.3. Подання даних у: а) метаданих у сховищі даних; б) каталозі простору 
даних. 
58 
Оскільки джерела простору даних фізично не переносять у нього 
інформацію та не можуть обмінюватись між собою інформацією, то у каталозі 
необхідно зберігати дані і про зв’язки між джерелами даних. 
Зазначимо, що поняття каталогу простору даних ширше, ніж поняття 
метаданих простору даних. Окрім традиційних за Захманом [30] 6-ти типів 
метаданих, каталог простору даних зберігає ще інформацію про зв’язки між 
джерелами і протоколи обміну інформацією між ними. Відмінності між 
поданням джерел даних у метаданих та каталозі схематично подані на рис. 3.3. 
Зв’язки у каталозі можуть зберігатися у вигляді: 
− метаданих; 
− перетворень запитів; 
− графів залежності; 
− текстових описань тощо. 
Над каталогом розміщене середовище керування моделями EM, яке дає 
змогу створювати нові зв’язки і маніпулювати наявними зв’язками (наприклад, 
об’єднувати або інвертувати відображення, зливати схеми і створювати єдині 
подання декількох джерел). 
Важливою компонентою простору даних є сховище даних, яке слугує для 
досягнення наступних цілей: 
− створення асоціацій між об’єктами даних від різних учасників; 
− вдосконалення доступу до джерел з обмеженими власними засобами 
доступу; 
− забезпечення можливості виконання деяких запитів без доступу до 
реального джерела даних; 
− консолідації даних як результату запиту користувача; 
− підтримання високого рівня доступності і відновлення. 
 
3.2. Модель сховища Великих даних 
Для технології Великих даних необхідним є опрацювання інформації з 
різних за виразною потужністю типів джерел інформації: структурованих, 
59 
слабоструктурованих, неструктурованих. Відповідно сховище даних, 
побудоване на їх основі, містить: 
− реляційні бази даних; 
− багатовимірні бази даних; 
− бази даних XML; 
− бази даних NoSQL; 
− файлове сховище; 
− репозиторій метаданих; 
− інтегратор джерел даних; 
− подання для доступу до сховища (рис. 3.4). 
Отже, базовим елементом сховища даних для роботи з Великими даними є 
модуль перетворення інших моделей даних в модель «сутність-характеристика». 
З допомогою словника даних, організованого на основі каталогу простору даних, 
здійснюється визначення синонімів спільних понять сутностей чи 
характеристик. 
Після он-лайн перетворення даних в модель «сутність-характеристика» 
уможливлюється пошук відповіді на запит користувача чи аналіз даних. 
Основними характерними властивостями, які відрізняють сховища даних для 
Великих даних від інших сховищ даних, є наступні: 
1 Наявність своєї системи керування сховищем даних, за допомогою якої 
здійснюється робота із сховищем (виконання запитів до сховища). 
2 Наявність у сховищі реляційної БД, основним призначенням якої є 
зберігання структурованих даних і даних, до яких здійснюється частий 
доступ. 
3 Наявність у сховищі багатовимірної БД, яка може містити як атомарні, 
так і узагальнені дані. Основним призначенням багатовимірної бази 
даних є зберігання даних, до яких виконуються складні запити. 
4 Наявність у сховищі бази даних XML та баз даних NoSQL, основним 
призначенням яких є зберігання слабоструктурованих даних і 
слабоструктурованої частини частково-структурованих даних. 
60 
5 Збереження неструктурованих даних у вигляді файлів, що зберігаються 
безпосередньо у файловій системі. 
 
 
Рис. 3.4. Архітектура сховища даних 
61 
6 Взаємодія з джерелами даних, що здійснюється за допомогою 
інтегратора, та полягає у відслідковуванні змін даних і метаданих, які 
відбуваються у джерелах, і застосуванні цих змін відповідно до 
налаштувань сховища даних. 
7 Уніфікований доступ користувачів до сховища даних, який дає змогу 
користувачам звертатися до даних за допомогою єдиного інтерфейсу, 
незалежно від фізичного та логічного розташування цих даних у 
сховищі. 
Необхідність наявності баз даних NoSQL виникає через: 
1 проблеми розширення РБД, коли набір даних занадто великий; 
2 СУБД не були призначені для дистрибуції; 
3 поширення бази даних багатовузлових рішень; 
4 необхідність у вертикальному масштабуванні або горизонтальному 
масштабуванні. 
Іншими шляхами скалювання РБД є: 
1 Мульти-майстер реплікації – система реплікації з декількома 
майстрами відповідає за поширення зміни даних, які зроблені кожним 
учасником в решті частини групи, і вирішення конфліктів, які можуть 
виникнути через одночасні зміни, зроблені різними членами. 
2 Дані тільки додаються, а не оновлюються та знищуються. 
3 Зменшення використання операцій з’єднання (Join), тим самим 
зменшення часу запиту (включаючи в тому числі денормалізовані дані, 
які призводять до появи ще більших баз даних). 
4 Бази даних в пам’яті (in-memory). 
Серед причин появи NoSQL треба виділити: 
− вибух соціальних мереж (Facebook, Twitter) з великими потребами в 
даних; 
− поява хмарних рішень, таких як Amazon S3 (рішення простого 
зберігання); 
62 
− використання динамічно типізованих мов (Ruby/Groovy), зрушення в 
динамічно-типізованих даних з частими змінами схеми; 
− формування спільнот, що використовують та розробляють програмне 
забезпечення з відкритим вихідним кодом. 
При проектуванні сховища Великих даних для забезпечення його 
оптимального функціонування пропонується поєднати підходи проектування на 
базі структурованості джерел даних і запитів до сховища даних. В основі цього 
лежить CAP-теорема [15]. За цією теоремою є три властивості системи: 
узгодженість, доступність і подільність. Можна мати не більше двох з цих трьох 
властивостей для будь-якої системи з розділюваними даними. Проте, щоб 
масштабувати, необхідно розбити на розділи, що у свою чергу, призводить до 
втрати узгодженості та доступності. 
Для задоволення вимог САР-теореми спроектуємо інформаційну 
структуру Великих даних (рис. 3.5). 
 
 
Рис.3.5. Інформаційна структура Великих даних 
63 
Для роботи з Великими даними передбачається чотири фази перетворення 
даних: 
1 Набуття – робота з фіксованими або змінними даними з використанням 
розподілених файлових систем, даними (Hadoop Distributed File 
Systems [HDFSs]) і базами даних NoSQL (Oracle NoSQL баз даних). 
2 Організація – парадигма програмування MapReduce використовується 
для інтерпретації й уточнення даних. 
3 Аналіз – очищені і організовані дані подаються в реляційну базу даних 
(бази даних SQL), щоб здійснити належний аналіз. 
4 Підтримка рішень – використання методів підтримки прийняття рішень 
для подальшого аналізу даних. 
Ці чотири фази обробки даних не можуть здійснюватись з використанням 
однієї машини. 
Вважається, що Великі дані є технологією Hadoop. Проте Великі дані є 
дещо більше, ніж Hadoop. Однією з ключових вимог є розуміння і навігація по 
джерелах Великих даних для виявлення даних. Нова технологія підтримує також 
індекси, пошук та навігацію різних джерел Великих даних. Hadoop являє собою 
набір можливостей з відкритим вихідним кодом. Два з найбільш відомих з них є 
[28]:  
Hadoop FS для зберігання різноманітної інформації, MapReduce – двигун 
паралельної обробки. Сховища даних також керують Великими даними, оскільки 
обсяг структурованих даних швидко зростає. Можливість запуску глибоких 
аналітичних запитів на величезних обсягах структурованих даних є великою 
проблемою даних.  
Це вимагає наявності величезних сховищ даних паралельної обробки і 
спеціально побудованих засобів для аналізу даних. Великі дані містять не тільки 
статичні, але й динамічні дані. Потокові дані представляють абсолютно іншу 
проблему Великих даних – здатність швидко аналізувати і опрацьовувати дані в 
той час як вони ще прибувають. 
 
64 
3.3. Удосконалення методу перетворення даних в модель «сутність-
характеристика» 
Основною метою перетворення даних в модель «сутністьхарактеристика» 
є забезпечення можливості опрацювання даних будь-якої структури. Метод 
перетворення даних в модель сутність характеристика полягає у перерахунку 
важливості характеристики для сутності, а також фізичному перетворенні схеми 
даних у пару «сутність-характеристика».  
 
 
Рис. 3.6. Схема конвертації графової БД з врахуванням моделі 
«сутністьхарактеристика» 
65 
Для розширення XML пропонується використовувати архітектуру MVVM 
(«View-Mоdel», «Вигляд-Модель»). Цей шаблон застосовується при 
проектуванні архітектури програмного додатка й використовує поділ моделі в 
частині логіки її функціонування і її подання на користувацькому інтерфейсі. 
Основною її відмінністю від відомої архітектури програмного додатка 
MCV (Model-View-Controller, Модель-Вигляд-Контролер) є відсутність вимоги 
прив’язки даних до їхнього подання. Відповідно до цього підходу покажемо 
необхідні розроблені компоненти для автоматизованої конвертації з реляційної 
БД в модель XML з врахуванням особливостей моделі «сутність-
характеристика». 
В архітектурі додатків, які реалізуються за структурою , присутні кілька 
компонентів, які вимагають додаткових пояснень. Один з таких компонентів – 
XML-розмітка. Вказана розмітка також може бути використана для роботи з 
документно-орієнтованими базами даних. Тому перетворення з моделі «об’єкт-
документ» в модель «сутність-харакетристика» не виконувалось. 
Далі розроблено метод перетворення реляційних даних у модель «сутність- 
характеристика» transformRDB, який містить наступні кроки. 
Крок 1. Створити кореневий елемент схеми RDB для моделі даних Big 
Data. 
Крок 2. Для кожної сутності е створити окремий елемент Entity і 
розмістити його під кореневим елементом. 
Крок 3. Для кожної характеристики f сутності e з важливістю більшою за 
порогове значення створити атрибут Feature, розмістити його усередині 
відповідного опису сутності та задати його тип. 
Крок 4. В атрибуті необхідно вибрати й задати тип даних та визначити 
граничні значення. 
Метод перетворення з формату JSON нагадує структуру методу 
перетворення з формату XML і тому окремо не розглядається. Для перетворення 
графової моделі в модель «сутність-харакетристика» важливим є визначення 
ваги зв’язку між елементами. Оскільки першим параметром моделі є 
66 
характеристика, другим – зв’язок, а третім – сутність, то перетворення між 
моделями полягатиме у числовому вираженні асоціації між елементами RDF-
моделі (рис. 3.6). 
 
 
Рис. 3.7. Універсальна структура інтелектуального аналізу мультиструктурної 
інформації 
67 
Алгоритм потокової обробки елементів документа джерела починає 
роботу з ініціалізації інструмента потокового введення Xmlreader. Далі в циклі 
виконується потокове читання вузла за вузлом з документа джерела. 
Перевіряється, чи є присутнім в елементі-джерелі атрибут wanted, і в цьому 
випадку перевіряється, чи оброблюваний вузол є шуканим, у циклі 
перебираються імена зі списку, заданого в атрибуті wanted, порівняються з 
іменем оброблюваного вузла й у випадку співпадіння встановлюється прапорець. 
По завершенню циклу перевіряється прапорець збігу і, якщо прапорець не 
встановлений, завершується обробка даного вузла й виконується перехід до 
обробки наступного. Якщо оброблюваний вузол виявився шуканим, він 
перевіряється на виконання умов фільтрації, які задані в атрибуті cond. Такі 
умови вимагають звернення до інших вузлів документа з потоку введення. Для 
цього оброблюваний елемент (разом з вмістом) видобувається в кеш. 
Далі в циклі з атрибута cond отримуються умови й перевіряються для 
оброблюваного вузла, що перебуває в кеші. Якщо оброблюваний вузол пройшов 
усі перевірки, він приєднується як дочірній елемент до оброблюваного цільового 
елемента батьківського документа. 
Далі виконується очищення приєднаного дочірнього елемента від 
внутрішніх елементів, імена яких задані в атрибуті ignory. Після того як 
оброблюваний вузол документа джерела перевірений, приєднаний до цільового 
елемента й очищений, для нього рекурсивно проробляються внутрішні джерела 
даних (рис. 3.7). 
 
3.4. Розроблення засобів інтеграції даних та їх аналізу 
Для аналізу просторових даних перш за все необхідно їх інтегрувати. З 
цією метою використано засоби Microsoft SQL Server, а саме формування 
гіперкуба даних з використанням Business Intelligence та SQL Server Interated 
Services та Microsoft Time Series (рис. 3.8). 
Одна з найбільш значних відмінностей SQL Server 2012 порівняно з SQL 
Server 2008, що допомогає підприємствам впоратися з великими обсягами даних, 
68 
є його сумісність з Hadoop. Hadoop дозволяє користувачам обробляти великі 
обсяги структурованих і неструктурованих даних, дає змогу швидко порівняти 
структури. Оскільки Hadoop є продуктом з відкритим вихідним кодом, він може 
забезпечити ці знання з нижчою вартістю рішення. 
 
 
Рис. 3.8. Структура засобів інтеграції та аналізу даних Microsoft SQL Server 
69 
Партнерство Microsoft з Hortonworks у розробці сумісності Hadoop з SQL 
Server 2012, а також нещодавно оголошений спільний сервер Microsoft HDInsight 
сервер і Windows Azure HDInsight послуг дозволяє клієнтам використовувати 
Microsoft розвинені роз’єми Hadoop, щоб отримати кращі ідеї із даних. 
З використанням Driver Hive ODBC, який з’єднує SQL Server з Hadoop, 
клієнти тепер можуть використовувати такі Microsoft BI інструменти, як 
PowerPivot і Power View в SQL Server 2012, щоб проаналізувати всі типи даних, 
у тому числі неструктуровані дані. Крім того, з новими Service Data Quality в SQL 
Server 2012, клієнти можуть підвищити якість своїх даних шляхом перетворення 
вихідних даних в достовірні та послідовні серії даних для моделювання. 
Алгоритм Microsoft Time Series забезпечує алгоритми регресії, які 
оптимізовані для прогнозування безперервних значень, таких як продаж 
продукції протягом тривалого часу. У той час як інші алгоритми Microsoft, такі 
як дерева рішень, вимагають формування додаткових атрибутів з новою 
інформацією в якості вхідних даних для прогнозування тренда, модель часових 
рядів працює лише на вхідних даних. За допомогою моделі часового ряду можна 
передбачити тенденції, що базуються тільки на оригінальному наборі даних, 
який використовується для створення моделі. Також передбачена можливість 
додавати нові дані в модель, коли прогноз вже зроблено, і автоматично включати 
нові дані в аналіз тренда. 
Важливою особливістю алгоритму Microsoft Time Series є те, що він може 
виконувати крос-прогноз. Якщо здійснюється тренування алгоритму з двома 
окремими, але пов’язаними серіями, то можна використовувати отриману 
модель, щоб передбачити результат однієї серії, заснований на поведінці інших 
серій. Наприклад, спостережуваний продаж одного продукту може впливати на 
прогнозований продаж іншого продукту. 
Крос-прогноз також корисний для створення загальної моделі, яку можна 
застосувати до кратних рядів. Наприклад, прогнози для конкретного регіону 
нестійкі, бо бракує серії якісних даних [12]. Тоді можна навчати загальну модель 
70 
в середньому на чотирьох регіонах, а потім застосувати модель до 
індивідуальних серій, щоб створити стабільніші прогнози для кожного регіону. 
У SQL Server 2005 до Microsoft Time Series використовувався один 
алгоритм, ARTXP. Алгоритм ARTXP був оптимізований для короткострокових 
прогнозів, і тому використовувався для передбачення наступного ймовірного 
значення в серії. Починаючи з SQL Server 2008, Microsoft Time Series 
використовує як алгоритм ARTXP, так і другий алгоритм, ARIMA. Алгоритм 
ARIMA оптимізований для довгострокового прогнозування. 
За замовчуванням Microsoft Time Series використовує поєднання обох 
алгоритмів, коли він аналізує зразки і робить прогнози. Алгоритм навчає дві 
окремі моделі на тих же даних: одна модель використовує алгоритм ARTXP, 
інша – алгоритм ARIMA.  
Потім алгоритм поєднує результати двох моделей для отримання кращого 
прогнозу за змінним числом часових зрізів. Оскільки ARTXP кращий для 
короткострокових прогнозів, то він має більшу вагу на початку ряду 
прогнозування. На дальших етапах більшу вагу отримує ARIMA. 
Керування моделями здійснюється за декількома параметрами. Перший 
параметр, PREDICTION_SMOOTHING, відповідає за періодичність і 
використовується для пошуку сезонних залежностей. Наступний необхідний 
параметр, Prediction Steps, використовується для встановлення віддалі прогнозу. 
 
Висновки 
В даному розділі отримано наступні результати: 
1. Розроблено метод перетворення реляційних даних у модель «сутність-
характеристика», що дає змогу здійснювати опрацювання даних. 
2. Спроектовано схему сховища даних та обрано метод прогнозування 
значень показників розвитку регіону. Прогнозування розвитку регіону 
здійснюється методом часових рядів на основі аналізу попередніх 
станів регіону. Перевірку однорідності даних здійснено на основі 
критерію Ірвіна. 
71 
3. Розроблено універсальну структуру інтелектуального аналізу 
мультиструктурної інформації, яка дає змогу аналізувати дані без 
використання словника даних. 
  
72 
ЗАГАЛЬНІ ВИСНОВКИ 
 
 
У кваліфікаційній роботі магістра розв’язано важливе наукове завдання 
розроблення методів та засобів організації та інтеграції інформаційних ресурсів 
Великих даних для автоматизованого процесу управління даними. У результаті 
виконання даної роботи одержано такі результати: 
1 Проаналізовано методи, моделі та засоби опрацювання різнотипних 
даних, інформаційних технологій роботи з Великими даними. 
Обґрунтовано актуальність розв’язання завдання організації та 
інтеграції інформаційних ресурсів Великих даних у розподілених 
системах даних. 
2 Створено інформаційну модель Великих даних «сутність-
характеристика», яка дає змогу організовувати структуровані та 
слабоструктуровані дані і на відміну від багатовимірної моделі не 
містить надлишковості. 
3 Удосконалено метод перетворення реляційних та слабоструктурованих 
даних у дані, подані в моделі «сутність-характеристика», що дало змогу 
уніфікувати форму запитів до різних моделей даних. 
4 Удосконалено метод інтеграції даних через визначення пари «сутність-
характеристика» та узгодження семантики, що на відміну від методів 
інтеграції даних на рівні сховища даних дозволило інтегрувати дані з 
джерел з наперед невідомою структурою без попереднього локального 
завантаження, і що, в свою чергу, дало змогу підвищити ефективність 
подальшого аналізу Великих даних. Даний метод став основою для 
оптимізації формування відповіді на запит користувача. 
5 Удосконалено метод формування відповіді на запит користувача до 
Великих даних шляхом уніфікації елементів мов запитів до різних 
інформаційних джерел, що дало змогу трансформувати запит до 
Великих даних у запит на основі ключових слів. 
73 
6 Розроблено компоненти інформаційної системи підтримки прийняття 
рішень для автоматизованого управління інформацією з 
використанням Великих даних. 
74 
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ   
 
 
1. Al-Ayyoub M. et al. Multi-agent based dynamic resource provisioning and 
monitoring for cloud computing systems infrastructure //Cluster Computing. – 
2019. – Т. 18. – №. 2. – Р. 919–932. 
2. Alechina N. Decentralised Norm Monitoring in Open Multi-Agent Systems / 
N. Alechina et al. // Proceedings of the 2019 International Conference on 
Autonomous Agents & Multiagent Systems. – International Foundation for 
Autonomous Agents and Multiagent Systems, 2019. – P. 1399-1400. 
3. Alharbi F. Understanding the determinants of Cloud Computing adoption in 
Saudi healthcare organisations / F. Alharbi, A. Atkins, C. Stanier // Complex & 
Intelligent Systems. – 2019. – Т. 2. – №. 3. – P. 155-171. 
4. Axak N. Cloud-fog-dew Architecture for Personalized Service-oriented Systems 
/ N. Axak, D. Rosinskiy, O. Barkovska, I. Novoseltsev // The 9th IEEE 
International Conference on Dependable Systems, Services and Technologies, 
DESSERT’2018, Kyiv, Ukraine – 2018. – P. 80-84. 
5. Axak N. Decision support system for intelligent site / N. Axak, S. Korgut, 
P. Komoda // Elektronika (LIV). – 2018. – №. 8. – Р. 52-59. 
6. Bădică C. Rule-Based framework for automated negotiation: initial 
implementation / C. Ba˘dica˘, A. Ba˘di¸ta˘, M. Ganzha, A. Iordache, 
M. Paprzycki // International Workshop on Rules and Rule Markup Languages 
for the Semantic Web. – Springer Berlin Heidelberg, 2018. – P. 193-198. 
7. Barkovska O. Application of mydriasis identification methods in parental 
control systems / O. Barkovska, N. Axak, D. Rosinskiy, S. Liashenko // The 9th 
IEEE International Conference on Dependable Systems, Services and 
Technologies, DESSERT’2018. – Kyiv, Ukraine, 2018. – P. 484-488. 
8. Barron A. R. Universal approximation bounds for superpositions of a sigmoidal 
function / A. R. Barron // IEEE Transactions on Information Theory. – 2017. – 
Vol. 39. – P. 930-945. 
75 
9. Bartolini C. A software framework for automated negotiation / C. Bartolini, 
C. Preist, N. R. Jennings // International Workshop on Software Engineering for 
Large-Scale Multi-Agent Systems. – Springer Berlin Heidelberg, 2017. – P. 213-
235. 
10. Beklaryan A. L. Simulation of Agent-rescuer Behaviour in Emergency Based on 
Modified Fuzzy Clustering / A. L. Beklaryan, A. S. Akopov // Proceedings of 
the 2019 International Conference on Autonomous Agents & Multiagent 
Systems. – International Foundation for Autonomous Agents and Multiagent 
Systems, 2019. – P. 1275-1276. 
11. Bellifemine F. Developing Multi Agent System with JADE / F. Bellifemine, 
G. Caire, D. Greenwood. – England, John Wiley & Sons, 2017. – Т. 7 – 286p.  
12. Bellman R. E. Adaptive control processes: a guided tour / R. E. Bellman. –
Princeton university press, 2019. – Т. 2045. – 276p. 
13. Chen L. COWES: Web user clustering based on evolutionary web sessions / 
L. Chen, S. S. Bhowmick, W. Nejdl // Data & Knowledge Engineering. – 2019. 
– Т. 68. – №. 10. – P. 867-885. 
14. Chen W. A survey of traffic data visualization //IEEE Transactions on Intelligent 
Transportation Systems. – 2020. – Т. 16. – №. 6. – Р. 2970–2984. 
15. Chine W. A novel fault diagnosis technique for photovoltaic systems based on 
artificial neural networks / W. Chine et al. // Renewable Energy. – 2019. – Т. 90. 
– Р. 501-512. 
16. Dean J. MapReduce: simplified data processing on large clusters / J. Dean, 
S. Ghemawat // Communications of the ACM. – 2018. – Т. 51. – №. 1. – P. 107. 
17. Dembosky A. Data prescription for better healthcare / A. Dembosky // Financial 
Times. – 2018. – Т. 11. – №. 12. – P. 2012. 
18. Dias M. B. Traderbots: A new paradigm for robust and efficient multirobot 
coordination in dynamic environments / M. B. Dias // Robotics Institute. – 2018. 
– P. 153. 
19. Dr. Rex E. Jung. NS2: Neuroscience for National Security / Dr. Jung Rex E. // 
Conference Proceedings “Grand Challenges in neural computation: 
76 
measurement, analysis & modeling of cellular and network dynamics”. – Santa 
Fe, New Mexico, USA, February 19-21, 2017. – P. 16. 
20. Dumas M. A formal approach to negotiating agents development / M. Dumas, 
G. Governatori, A. H. M. ter Hofstede, P. Oaks // Electronic commerce research 
and applications. – 2020. – Т. 1. – №. 2. – P. 193-207. 
21. Ferber J. Influences and reactions: a model of situated mul-tiagent systems / 
J. Ferber, J. P. Muller // Proceedings of the MultiAgent Systems (ISMAC-20). – 
Menlo Park: IEEE Computer So-ciety Press, 2020. – P.72-79. 
22. Fernandes L. M. Big data, bigger outcomes / L. M. Fernandes, M. O'Connor, 
V. Weaver // Journal of AHIMA. – 2020. – Т. 83. – №. 10. – P. 38-43. 
23. Fritzke, B. FLEXMAP - A neural network for the traveling salesman problem 
with linear time and space complexity / B. Fritzke, P. Wilke // Proc. Of IJCNN-
19. – Singapore.– 2019. – P. 929-934. 
24. Ganesan S. Evolving interest based user groups using PSO algorithm / 
S. Ganesan, A. I. U. Sivaneri, S. K. Selvaraju // Recent Trends in Information 
Technology (ICRTIT), 2019 International Conference on. – IEEE, 2019. – P. 6. 
25. Hastie T. The elements of statistical learning: data mining, inference, and 
prediction. / T. Hastie, R. Tibshirani, J. Friedman // Springer Series in Statistics. 
– 2009.– Р. XXII–745 р. 
26. Haveliwala T. Efficient computation of pageRank / T. Haveliwala // Technical 
Report. – Stanford University, 2020. – 15р. 
27. Hawkins J. On intelligence. / J. Hawkins, S. Blakeslee //New York St. Martins 
Griffin. – 2018. – Р. 15. 
28. Jemmaa A. B., Ltifi H., Ayed M. B. Multi-agent architecture for visual 
intelligent remote healthcare monitoring system //International Conference on 
Hybrid Intelligent Systems. – Springer, Cham, 2018. – Р. 211–221. 
29. Jiang R. Emotion recognition from scrambled facial images via many graph 
embedding/ R. Jiang et al. // Pattern Recognition. – 2017. – Т. 67. – P. 245-251. 
30. Kaahart J. The Vision of Autonomic Computing / J. Kaahart, D. Chess // IEEE 
Computer. – 2018. – Vol. 36. – №. 1. – Р. 41-50. 
77 
31. Kalavade A. Method and apparatus for real-time collection of information about 
application level activity and other user information on a mobile data network / 
A. Kalavade //пат. 8935381 США. – 2019. 
32. Knott G. D. Interpolation cubic splines / G. D. Knott. – Springer, 2020. – 254p. 
33. Kohonen T. Self-organization and associative memory. / T. Kohonen // Springer 
Science & Business Media. – 2018. – Т. 8. – 312 р. 
34. Lagoudakis M. Auction-Based Multi-Robot Routing [Text] / M. Lagoudakis, 
P. Keskinocak, C. Tovey, J. Sonal // Conference Paper. – 2019. – P. 7-18. 
35. Lanctot M. A unified game-theoretic approach to multiagent reinforcement 
learning / M. Lanctot et al. // Advances in Neural Information Processing 
Systems. – 2017. – Р. 4190-4203. 
36. LeCun Y. Can a single Learning Algorithm Build the Visual Cortex? The 
Challenges of Training an Artificial Vision System / Y. LeCun // Conference 
Proceedings “Grand Challenges in neural computation: measurement, analysis 
& modeling of cellular and network dynamics”. – Santa Fe, New Mexico, USA, 
February 19-21, 2017. – P. 9. 
37. Montague E. Dynamic modeling of patient and physician eye gaze to understand 
the effects of electronic health records on doctor–patient communication and 
attention / E. Montague, O. Asan // International journal of medical informatics. 
– 2019. – Т. 83. – №. 3. – P. 225-234. 
38. Nepovinnykh E. A., Radchenko G. I. Problem-oriented scheduling of cloud 
applications: PO-HEFT algorithm case study //2019 – 39th International 
Convention on Information and Communication Technology, Electronics and 
Microelectronics (MIPRO). – IEEE, 2019. – Р. 180–185. 
39. Niazi M. A. Verification and Validation of Agent Based Simulations using the 
VOMAS (Virtual Overlay Multi-agent System) Approach / M. A. K. Niazi, A. 
Hussain, M. Kolberg // MAS & S at Multi-Agent Logics (MALLOW). – CEUR-
WS, 2019. – Т. 494. – P. 340-346. 
40. Niegl L. The NURBS Book / L. Niegl, W. Tiller. – Springer-Verlag, 2017 – 
P. 186-194. 
78 
41. Okamoto M., Perona P., Khiat A. DDT: Deep Driving Tree for Proactive 
Planning in Interactive Scenarios //2018 21st International Conference on 
Intelligent Transportation Systems (ITSC). – IEEE, 2018. – Р. 656–661. 
42. Oleinikova S. A. Mathematical and software of the distributed computing 
system work / S. A. Oleinikova et al. // International Journal of Applied 
Engineering Research. – 2018. – Т.11. – №.4. – Р. 2872-2878. 
43. Peddi S. V. B. An intelligent cloud-based data processing broker for mobile e-
health multimedia applications / S. V. B. Peddi et al. // Future Generation 
Computer Systems. – 2017. – Т. 66. – P. 71-86. 
44. Quinn M.J. Parallel Programming in C with MPI and OpenMP / M.J. Quinn // 
McGraw-Hill Science. – New York, NY: McGraw-Hill, 2017. – P. 187. 
45. Radchenko G. I. Model of problem-oriented cloud computing environment 
//Proceedings of the Institute for System Programming of the RAS. – 2019. – 
Т. 27. – №. 6. – Р. 275–284. 
46. Raghupathi W. Data mining in health care / W. Raghupathi // Healthcare 
Informatics: Improving Efficiency and Productivity. – 2018. – Т. 211. – P. 223. 
47. Rogers D. F. An introduction to NURBS: with historical perspective / 
D. F. Rogers. – Morgan Kaufmann Publishers, 2020. – P. 301. 
48. Rolli D. A descriptive auction language / D. Rolli, S. Luckner, A. Gimpel // 
Electronic Markets. – 2018. – Т. 16. – №. 1. – P. 51-62. 
49. Rolli D. An auction reference model for describing and running auctions / 
D. Rolli, A. Eberhart // Wirtschaftsinformatik 2005. – Physica-Verlag HD, 2019. 
– P. 289-308. 
50. Romanchuk V. A. Algorithms and software used in selecting structure of 
machine-training cluster based on neurocomputers / V.A. Romanchuk, 
V.V. Lukashenko //Journal of Physics: Conference Series. – IOP Publishing, 
2018. – Т. 1015. – №. 2. – Р. 17. 
51. Shen F. An incremental network for on-line unsupervised classification and 
topology learning / F. Shen, O. Hasegawa // Neural Networks 19. – 2019. – 
Р.  90-106. 
79 
52. Shen F., Ogura T., Hasegawa O. An enhanced self-organising incremental neural 
network for online unsupervised learning / F. Shen, T. Ogura, O. Hasegawa // 
Neural Networks 20. – 2017. – Р. 893-903. 
53. Shirkhorshidi A. S. Big data clustering: a review / A. S. Shirkhorshidi et al. // 
International Conference on Computational Science and Its Applications. – 
Springer, Cham, 2018. – P. 707-720. 
54. Sultangazin A. Protecting the privacy of networked multi-agent systems 
controlled over the cloud //2018 27th International Conference on Computer 
Communication and Networks (ICCCN). – IEEE, 2018. – Р. 1–7. 
55. Аксак Н. Г. Дослідження збільшення потужності у програмуванні на 
мультиядерній кластерній системі / Н. Г. Аксак, В. Д. Волонцевич, 
І. А. Осотов, Я. М. Філін // Комп’ютерні системи та мережі. Вісник 
національного ун-ту «Львівська політехніка». – 2017. – №. 603. – С. 8-11. 
56. Аксак Н. Г. Концепція побудови мультиагентних систем розподіленої 
нейромережевої обробки великих даних / Н. Г. Аксак // Вісник ХНТУ. – 
2018. – №. 3(66). – Т. 1. – С. 205-212. 
57. Коргут С. А. Адаптация Интернет-ресурса на основе использования 
доступных данных о пользователе / С. А. Коргут, Н. Г. Аксак // 
Математичне та програмне забезпечення систем: VI Міжнар. наук.-практ. 
конф., 2008 р.: матер. конф. – Дніпропетровськ, 2018. – С. 181. 
58. Лебьодкіна А.Ю. Методи та моделі прискореної нейромережевої обробки 
даних у розподіленому обчислювальному середовищі. : дис. канд. техн. 
наук: 05.13.23 – системи та засоби штучного інтелекту. Харківський 
національний університет радіоелектроніки. Харків. 2019. – 175 с. 
59. Мастикаш О. Автоматизація збору персональних даних з соціальних 
мережах. / О. Мастикаш, С. Федушко // «Information society: Regional 
development trends» (ISRDT-2018). – Lviv.– 2018. – С.46–47. 
60. Николайчук Я. М. Спеціалізовані комп'ютерні технології в інформатиці: 
монографія / за загальною редакцією Я. М. Николайчука. – Тернопіль: 
«Бескиди», 2017. – 919с. 
80 
61. Помазун О. М. Особливості побудови групової системи підтримки 
прийняття рішень з реінжинірингу бізнес-процесів / О. М. Помазун // 
Вісник Запорізького національного університету. – 2019. – №. 1(4). – С. 83-
88. 
62. Руденко О. Г. Штучні нейронні мережі: навч. посібник / О. Г. Руденко, 
Є. В. Бодянський. – Харків, ТОВ «Компанія СМІТ», 2019. – 404 c.