Please use this identifier to cite or link to this item: https://er.chdtu.edu.ua/handle/ChSTU/9414
Title: Моделювання інформаційної системи для підвищення продуктивності функціонування сховищ структурованих даних
Authors: РУДНИЦЬКИЙ, Володимир
ВАСИЛЕНКО, Дар’я
Keywords: ІНФОРМАЦІЙНА СИСТЕМА;КЛАСТЕР;МОДЕЛЬ;АТРИБУТ;ПРЕДМЕТНА ОБЛАСТЬ;ТАБЛИЦЯ;ЗАПИТИ;СХОВИЩЕ ДАНИХ
Issue Date: 2022
Abstract: У кваліфікаційній роботі магістра було розглянуто теоретико-методологічні засади підвищення продуктивності інформаційних систем. Дано характеристику типових структур в інформаційних системах. Проаналізовано сучасні алгоритми підвищення продуктивності роботи сховища даних в інформаційних системах. Висвітлено процес розробки методики оптимізації моделі сховища даних на базі кластеризації атрибутів. Визначено предметну область підвищення продуктивності сховища даних. Представлено алгоритмічну модель субоптимального розподілу таблиць на базі кластерного аналізу груп запитів даних в інформаційній системі. Окреслено методики субоптимальної реструктуризації табличних структур сховища даних на основі багатомодального розподілу атрибутів. Охарактеризовано практичну складову моделі інформаційної системи для підвищення продуктивності функціонування сховищ структурованих даних на базі методик кластеризації атрибутів. Розроблено складові модуля зберігання даних в інформаційній системі. Окреслено схематизацію програмного забезпечення інформаційної системи.
URI: https://er.chdtu.edu.ua/handle/ChSTU/9414
Appears in Collections:123 Комп’ютерна інженерія (Комп'ютерні системи та мережі)

Files in This Item:
File Description SizeFormat 
РОБОТА_Василенко_Друк-merged.pdf
  Restricted Access
7.1 MBAdobe PDFView/Open Request a copy


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

Extracted text
МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ
ЧЕРКАСЬКИЙ ДЕРЖАВНИЙ ТЕХНОЛОГІЧНИЙ УНІВЕРСИТЕТ
ФАКУЛЬТЕТ ІНФОРМАЦІЙНИХ ТЕХНОЛОГІЙ І СИСТЕМ
КАФЕДРА ІНФОРМАЦІЙНОЇ БЕЗПЕКИ
ТА КОМП’ЮТЕРНОЇ ІНЖЕНЕРІЇ
Пояснювальна записка
до кваліфікаційної роботи магістра
на тему: «Моделювання інформаційної системи
для підвищення продуктивності
функціонування сховищ структурованих
даних»
ЧДТУ.222315.001 ПЗ
Виконала: студентка 2 курсу, групи ЗМКМ–2105
спеціальності 123 – Комп’ютерна інженерія
за освітньою програмою – Комп’ютерні системи
та мережі
Дар’я ВАСИЛЕНКО
Керівник
д.т.н., професор
Володимир РУДНИЦЬКИЙ
Н. контроль
Світлана ГРЕСЬКО
Рецензент
Начальник відділу персоналу, к.т.н., доцент
Віталій ЗАЖОМА
«ЗАХИСТ ДОЗВОЛЯЮ»
Завідувач кафедри ІБ та КІ
д.т.н., професор ______ Володимир РУДНИЦЬКИЙ
Черкаси 2022 року
Форма № Н–9.01
Черкаський державний технологічний університет
Факультет інформаційних технологій і систем
Кафедра інформаційної безпеки та комп’ютерної інженерії
Освітньо–кваліфікаційний рівень Магістр
Спеціальність 123 – Комп’ютерна інженерія
Освітня програма Комп’ютерні системи та мережі
«ЗАТВЕРДЖУЮ»
Завідувач кафедри _____ Володимир РУДНИЦЬКИЙ
«20» жовтня 2022 року
ЗАВДАННЯ
на кваліфікаційну роботу магістра студенту
Василенко Дар’ї Павлівні
(прізвище, ім’я, по батькові)
1. Тема роботи Моделювання інформаційної системи для підвищення
продуктивності функціонування сховищ структурованих даних
Керівник роботи Рудницький Володимир Миколайович, д. т. н., професор
(прізвище, ім’я, по батькові, науковий ступінь, вчене звання)
затверджені наказом університету від «14» жовтня 2022 р. № 275/04
2. Строк подання студентом роботи 09.12.2022
3. Вихідні дані до роботи:
Azadeh A., Sharifi S., Saberi M. Design and Implementation of a Human Centered Expert System for
Improvement of Strategic Planning in a Manufacturer of Construction Products. Australian Journal of Basic
and Applied Sciences. 2009. Vol. 3. Is. 3. P. 2447-2458. Boroński, R., Bocewicz, G. Relational Database
Index Selection Algorithm. Communications in Computer and Information Science. 2014. Vol. 3. P. 338-
347. Борукаєв З. Х. Математичні та комп’ютерні моделі процесів вдосконалення механізмів функціо-
нування і розвитку систем організаційного правління: дис. .... д. т. наук: 01.05.02 / Інститут проблем
моделювання в енергетиці ім. Г. Є. Пухова. Київ, 2018. 342 с.
4. Зміст розрахунково–пояснювальної записки (перелік питань, що їх належить розробити):
Вступ
Розділ 1. Теоретико-методологічні засади підвищення продуктивності інформаційних систем
Розділ 2. Розробка методики оптимізації моделі сховища даних на базі кластеризації даних
Розділ 3. Модель інформаційної системи для підвищення продуктивності функціонування сховищ
структурованих даних на базі методик кластеризації атрибутів
Висновки
Список використаних джерел
5. Перелік графічного матеріалу (з точним зазначенням обов’язкових креслень, плакатів):
6. Консультанти розділів роботи
Підпис, дата
Розділ Прізвище, ініціали та
посада завдання видав завдання прийняв
консультанта
7. Дата видачі завдання 20 жовтня 2022 року
КАЛЕНДАРНИЙ ПЛАН
№ з/п Назва етапів кваліфікаційної роботи магістра Строк виконання
етапів роботи Примітка
1. Вибір і затвердження теми магістерської роботи 19.09.-19.10.2022 Виконано
Збір фактичного матеріалу. Розробка практичної
2. частини кваліфікаційної роботи магістра. Робота над 20.10–20.11.2022 Виконано
першим варіантом кваліфікаційної роботи магістра
3. Правка тексту магістерської роботи. 24.11–28.11.2020 Виконано
4. Усунення недоліків у кваліфікаційній роботі магістра 30.11–05.12.2021 Виконано
Остаточне оформлення кваліфікаційної роботи
5. магістра. Підготовка графічного матеріалу. Складання 29.11–06.12.2022 Виконано
тексту доповіді
6. Захист магістерської роботи 20.12.2022
Студент–магістрант ____________________________ Дар’я ВАСИЛЕНКО
(підпис)
Керівник роботи _____________________________ Володимир РУДНИЦЬКИЙ
(підпис)
АНОТАЦІЯ
Тема: Моделювання інформаційної системи для підвищення
продуктивності функціонування сховищ структурованих даних
Записка: 95 сторінок, 37 рисунків, 22 таблиці, 25 літературних джерел.
У кваліфікаційній роботі магістра було розглянуто теоретико-
методологічні засади підвищення продуктивності інформаційних систем.
Дано характеристику типових структур в інформаційних системах.
Проаналізовано сучасні алгоритми підвищення продуктивності роботи
сховища даних в інформаційних системах. Висвітлено процес розробки
методики оптимізації моделі сховища даних на базі кластеризації атрибутів.
Визначено предметну область підвищення продуктивності сховища даних.
Представлено алгоритмічну модель субоптимального розподілу таблиць на
базі кластерного аналізу груп запитів даних в інформаційній системі.
Окреслено методики субоптимальної реструктуризації табличних структур
сховища даних на основі багатомодального розподілу атрибутів.
Охарактеризовано практичну складову моделі інформаційної системи для
підвищення продуктивності функціонування сховищ структурованих даних
на базі методик кластеризації атрибутів. Розроблено складові модуля
зберігання даних в інформаційній системі. Окреслено схематизацію
програмного забезпечення інформаційної системи.
Ключові слова: ІНФОРМАЦІЙНА СИСТЕМА, КЛАСТЕР, МОДЕЛЬ,
АТРИБУТ, ПРЕДМЕТНА ОБЛАСТЬ, ТАБЛИЦЯ, ЗАПИТИ, СХОВИЩЕ
ДАНИХ.
ANNOTATION
Theme: Modeling of the information system aimed at increasing the
efficiency of the structured data storages.
Note: 95 pages, 37 figures, 22 tables, 25 literary sources.
The master's thesis considered the theoretical and methodological principles
of improving the productivity of the information systems. The characteristic of
typical structures in information systems is given. Modern algorithms for
increasing the productivity of data storage in information systems are analyzed.
The process of developing a method for optimizing a data storage model based on
attribute clustering is highlighted. The subject area of improving the productivity
of the data warehouse is defined. An algorithmic model of suboptimal distribution
of tables based on cluster analysis of groups of data requests in the information
system is presented. Methods of suboptimal restructuring of tabular structures of
data storage based on multimodal distribution of attributes are outlined. The
practical component of the information system model for increasing the efficiency
of the structured data storage based on attribute clustering methods is
characterized. The components of the data storage module in the information
system have been developed. Schematization of information system software is
outlined.
Keywords: INFORMATION SYSTEM, CLUSTER, MODEL,
ATTRIBUTE, SUBJECT AREA, TABLE, QUERIES, DATA STORAGE.
ЗМІСТ
ВСТУП…………………………………………………………………………... 4
РОЗДІЛ 1 ТЕОРЕТИКО–МЕТОДОЛОГІЧНІ ЗАСАДИ
ПІДВИЩЕННЯ ПРОДУКТИВНОСТІ ІНФОРМАЦІЙНИХ СИСТЕМ.. 10
1.1 Розгляд типових структур в інформаційних системах...................... 10
1.2 Альтернативні схеми організації інформаційних систем: критерії
відбору…………………………………………………………………….. 25
1.3 Сучасні алгоритми підвищення продуктивності роботи сховища
даних в інформаційних системах….…….................................................. 29
1.4 Висновки до розділу 1………………………………………………... 42
РОЗДІЛ 2 РОЗРОБКА МЕТОДИКИ ОПТИМІЗАЦІЇ МОДЕЛІ
СХОВИЩА ДАНИХ НА БАЗІ КЛАСТЕРИЗАЦІЇ АТРИБУТІВ..……… 43
2.1 Визначення предметної області підвищення продуктивності
сховища даних…………………..............………………………………... 43
2.2 Алгоритмічна модель субоптимального розподілу таблиць на базі
кластерного аналізу груп запитів даних в інформаційної системи...…. 52
2.3 Представлення методики субоптимальної реструктуризації
табличних структур сховища даних на основі багатомодального
розподілу атрибутів………………………………………………………. 60
2.4 Висновки до розділу 2………………………………………………... 69
РОЗДІЛ 3 МОДЕЛЬ ІНФОРМАЦІЙНОЇ СИСТЕМИ ДЛЯ
ПІДВИЩЕННЯ ПРОДУКТИВНОСТІ ФУНКЦІОНУВАННЯ
СХОВИЩ СТРУКТУРОВАНИХ ДАНИХ НА БАЗІ МЕТОДИК
КЛАСТЕРИЗАЦІЇ АТРИБУТІВ……………………………………………... 70
3.1 Структурні особливості інформаційної системи…………………... 70
3.2 Складові особливості модуля зберігання даних в інформаційній
системі…………………………………………………………………….. 76
3.3 Схематизація програмного забезпечення інформаційної системи... 83
3.4 Висновки до розділу 3………………………………………………... 89
ВИСНОВКИ…………………………………………………………………….. 90
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ………………….………………… 93
4
ВСТУП
Актуальність дослідження. На сучасному етапі розвитку суспільства
в галузі інформаційно-комунікаційних технологій спостерігається тенденція
до укрупнення і централізації програмного забезпечення, що розробляється.
Це зумовлено збільшенням доступності і смуги пропускання мережі Інтернет
для кінцевого користувача. Укрупнення і централізація є вирішенням
проблеми, пов’язаної з експлуатаційним обслуговуванням інформаційних
систем, що базуються на сховищах даних. На сьогоднішній день
інформаційне і методичне забезпечення прийняття рішень при виборі
способу підвищення продуктивності сховищ даних складається з набору
рекомендацій або розробляється для кожної компанії окремо, що ускладнює
процес прийняття рішень.
Поширення набули інформаційні системи із централізованим клієнт-
серверним сховищем даних. Цей факт обумовлений загальним інтерфейсом
взаємодії, наприклад, для мобільних додатків, настільних інформаційних
систем, вебсистем. Загальна схема організації даних широкого кола
інформаційних систем дозволяє зробити висновок необхідність виділення
єдиного структурного елемента – кліеєт-серверного сховища даних як
об’єкта дослідження. З цих причин розробка методичного забезпечення для
підвищення продуктивності сховищ даних є актуальним і затребуваним
завданням.
Питання вибору способів підвищення продуктивності інформаційних
систем широко висвітлено у працях: О. Додонов [7], В. Донець, Н. Кучук,
С. Шмакова [8; 12; 23], В. Лисак [13],
Окремі аспекти, пов’язані з аналізом і розробкою методів підвищення
продуктивності сховищ даних, розглянуті в роботах: А. Ажадех, С. Шафарі
[2], З. Борукаєв [4], У. Гелінас, С. Саттон, Дж. Федоровіч [6], В. Саутер [21],
С. Фіджеральд [22], Н. Ю, Р. Джонсон, та ін. [24].
5
До проблем і методів вирішення завдань кластерного аналізу можна
віднести роботи: Л. Беркман, О. Бараш та ін. [3], М. Жигайло [9; 10], питання
проєктування інформаційних систем розглядали такі науковці як
В. Авраменко, А. Авраменко [1], А. Марченко [14], М. Ковальчук [15], .
Проведені дослідження і публікації не вичерпують всіх проблем,
пов’язаних із вибором способу підвищення продуктивності інформаційних
систем за критерієм мінімального середнього часу виконання запитів на
читання інформації зі сховища даних. Також не достатньо розглянуті питання
аналізу запитів на читання даних як кінцевої групи, яка виявляється на етапі
експлуатації життєвого циклу інформаційної системи. Системний підхід до
створення методів підвищення продуктивності сховищ даних має активний
розвиток. Питання вирішення проблем падіння продуктивності на етапі
активної експлуатації інформаційних систем, заснованих на сховищах даних,
потребують подальших досліджень і розробки нових методик прийняття
рішень. Тому існує необхідність вивчення і розробки методичного
забезпечення підвищення продуктивності сховищ даних.
Об’єктом дослідження є табличні структури сховищ даних
інформаційних систем.
Предметом дослідження є застосування методик реструктуризації
структур даних сховищ підвищення продуктивності інформаційних систем.
Метою дослідження є підвищення продуктивності інформаційних
систем за допомогою розробки методичного забезпечення прискореної
обробки запитів сховищ даних.
Для досягнення поставленої мети необхідно вирішити такі завдання.
1. Провести аналіз методів і засобів підвищення продуктивності
інформаційних систем.
2. Формалізувати задачу оптимізації моделі даних інформаційних
сховищ у вигляді теоретико-множинної моделі.
6
3. Розробити евристичний алгоритм пошуку субоптимального поділу
таблиці, що базується на кластерному аналізі групи запитів для сховищ даних
великих інформаційних систем.
4. Розробити методики субоптимальної реструктуризації табличних
структур сховищ даних невеликих інформаційних систем на основі
багатомодального розподілу атрибутів.
5. Розробити систему підвищення продуктивності сховищ даних з
урахуванням методик кластеризації атрибутів.
Наукова новизна магістерської роботи полягає у розробці нових
підходів до реструктуризації сховищ даних для підвищення їхньої
продуктивності. Під час роботи над магістерським дослідженням було
отримано такі результати:
 формалізовано завдання оптимізації моделі даних інформаційних
сховищ у вигляді теоретико-множинної моделі;
 розроблено методики оптимізації моделі даних сховища на основі
кластеризації атрибутів;
 розроблено інформаційну систему підвищення продуктивності
сховищ даних на основі методик кластеризації атрибутів;
 проведено апробацію методик.
Результати, викладені у магістерській роботі, можуть бути використані
при вирішенні завдань підвищення продуктивності різних інформаційних
систем, що базуються на сховищах даних.
Теоретична значущість роботи полягає в тому, що в процесі
досліджень проаналізовано типові структури інформаційних систем, їх
переваги, недоліки, поширення: основними архітектурами інформаційних
систем є трирівнева архітектура з «тонким клієнтом» – браузером,
вебсервером і сховищем даних.
Систематизовано методи підвищення продуктивності інформаційних
систем на основі сховищ даних. Виявлено негативний вплив віку
інформаційної системи на її продуктивність. Проведено аналіз методів
7
підвищення продуктивності сховищ даних, за результатами якого було
виявлено їх переваги та недоліки. Обґрунтовано вибір методу зберігання
даних на основі вертикально розділених таблиць. Визначено вплив розміру
блоку даних фізичної моделі сховища на продуктивність. Запропоновано
евристичний алгоритм пошуку субоптимального поділу таблиці, що
базується на кластерному аналізі групи запитів для сховищ даних великих
інформаційних систем. Розроблено методику субоптимальної
реструктуризації табличних структур сховищ даних невеликих
інформаційних систем на основі багатомодального розподілу атрибутів.
Розроблена методика оптимізації моделі даних інформаційної системи
на основі кластеризації альфа-квазіеквівалентності дозволяє провести
кластерний аналіз групи запитів на читання інформації і вибрати розбиття
табличних структур даних, що мінімізує середній час виконання запитів.
Складність поліноміальна алгоритму.
Методика оптимальної реструктуризації табличних структур даних
невеликих інформаційних систем на основі багатомодального розподілу
дозволяє отримати розбиття табличних структур на основі угруповання
атрибутів за частотою їх появ у запитах на читання інформації. Складність
алгоритму логарифмічна.
Практична цінність отриманих результатів полягає в тому, що у
розробленій інформаційній системі реалізовані методики, що дозволяють:
 реструктурувати сховища даних для підвищення продуктивності на
18–22%. Також визначено оцінку впливу розміру атрибуту даних на час
виконання запитів для читання інформації визначальним впливом обсягу
переданих між твердотільним накопичувачем та інші видами пам’яті даних.
 підвищити продуктивність великих інформаційних систем за
рахунок реструктуризації даних на основі кластерного аналізу статистики
запитів, яка дозволяє мінімізувати середній час виконання запиту на читання
даних;
8
 підвищити продуктивність невеликих інформаційних систем за
рахунок оптимальної реструктуризації даних на багатомодальний розподіл
атрибутів.
Розроблено програмне забезпечення, яке реалізує методики
реструктуризації даних. Виконано у вигляді вебсистеми, що підвищує її
доступність. Програмне забезпечення генерує програмний код запитів
реструктуризації існуючої табличної структури даних, читання інформації з
урахуванням отриманої реструктуризації даних, оцінки ефективності
отриманих структур даних.
Методологія дослідження. При вирішенні поставлених завдань
використовувалися методи системного аналізу, теорії множин, методи
нечіткої кластеризації, об’єктно-орієнтований аналіз інформаційних систем.
Інформаційна система розроблена за допомогою мови програмування
C# на платформі ASP.NET MVC 5 (середовище розробки програмних
додатків Microsoft Visual Studio 2022).
Основна частина магістерської роботи викладена на 95 сторінках, у
тому числі: основний текст на 75 сторінках, вступ на 6 сторінках, висновки
на 3 сторінках, робота містить 37 рисунків, 22 таблиці, список використаних
джерел містить 24 назви на 3 сторінках.
У вступі подано характеристику структури роботи: актуальність, мета,
об’єкт, предмет, методи дослідження, завдання, наукове, теоретичне та
практичне значення магістерського дослідження.
Основна частина, згідно до поставлених нами завдань, повністю
розкриває зміст магістерського дослідження.
У першому розділі розглянуто теоретико-методологіні засади
підвищення продуктивності інформаційних систем. Дано характеристику
типових структур в інформаційних системах. Проаналізовано сучасні
алгоритми підвищення продуктивності роботи сховища даних в
інформаційних системах.
9
Другий розділ висвітлює процес розробки методики оптимізації
моделі сховища даних на базі кластеризації атрибутів. Визначено предметну
область підвищення продуктивності сховища даних. Представлено
алгоритмічну модель субоптимального розподілу таблиць на базі
кластерного аналізу груп запитів даних в інформаційній системі. Окреслення
методики субоптимальної реструктуризації табличних структур сховища
даних на основі багатомодального розподілу атрибутів.
У третьому розділі охарактеризовано практичну складову моделі
інформаційної системи для підвищення продуктивності функціонування
сховищ структурованих даних на базі методик кластеризації атрибутів.
Розроблено складові модуля зберігання даних в інформаційній системі.
Окреслено схематизацію програмного забезпечення інформаційної системи.
У висновках представлено підсумки дослідження згідно із
поставленими завданнями, які були визначені на початку дослідження й
відповідають тематиці магістерського дослідження.
10
РОЗДІЛ 1
ТЕОРЕТИКО–МЕТОДОЛОГІЧНІ ЗАСАДИ ПІДВИЩЕННЯ
ПРОДУКТИВНОСТІ ІНФОРМАЦІЙНИХ СИСТЕМ
1.1 Розгляд типових структур в інформаційних системах
У світі мережа Інтернет грає дуже важливу роль. За десятиліття із суто
технічного нововведення Інтернет перетворився на невід’ємну частину життя
сучасного суспільства. Відключення від Інтернету розглядається навіть як
загроза національній безпеці. Все це говорить про великі обсяги інформації,
що циркулюють по каналах зв’язку, що накопичуються в мережевих
сховищах.
Зберігання інформації, її структурування, підтримка функціоналу
додавання і зміни – основні завдання функціонування більшості
інформаційних систем.
У зв’язку зі зростанням інформаційних обсягів, зростаючих вимог до
мінімізації часу реакції інформаційної системи на дії користувача, питання
підвищення продуктивності інформаційних систем, заснованих на сховищах
даних, стає особливо актуальним.
Безліч інформаційних систем можна розділити на набір видів
відповідно до ступеня належності тій чи іншій видовій властивості.
Т. Кайт наводить класифікацію інформаційних систем за масштабом.
1. Одинарні інформаційні системи можуть містити декілька простих
додатків, пов’язаних загальним інформаційним фондом, і розраховані на
роботу одного користувача або групи користувачів, які розділяють за часом
одне робоче місце.
2. Групові інформаційні системи орієнтовані на колективне
використання інформації членами робочої групи 1 будуються на основі
локальної обчислювальної мережі.
11
3. Корпоративні інформаційні системи орієнтовані на великі компанії і
можуть підтримувати територіально рознесені вузли чи мережі [16, с. 23-24].
Класифікація інформаційних систем за масштабом представлена
рисунку 1.1.
Рисунок 1.1 – Класифікація інформаційних систем за масштабом
Класифікація інформаційних систем за способом організації
архітектури (за методикою взаємодії клієнта із сховищем даних). За способом
організації архітектури групові та корпоративні інформаційні системи
поділяються на класи.
1. Системи на основі архітектури файл–сервер (File Server, FS–модель).
Усі основні функції програми інформаційної системи розташовуються на
клієнті. На сервері знаходяться файли з даними і підтримується доступ до
даних. У цій моделі клієнт звертається до сервера на рівні файлових команд,
система управління файлами зчитує дані, що запитуються, зі сховища даних і
по блоках передає ці дані клієнтському додатку.
2. Системи на основі архітектури клієнт–сервер. Така система
характеризується наявністю двох взаємодіючих самостійних процесів –
клієнта і сервера, які можуть виконуватися на різних комп’ютерах,
12
обмінюючись даними в мережі. Особливістю архітектури клієнт–сервер є
наявність виділених серверів сховищ даних, що обробляють запити мовою
структурованих запитів (Structured Query Language, SQL) і виконують пошук,
сортування та агрегування інформації. Відмінна риса серверів сховищ
даних – наявність довідника даних, в якому зафіксовано структуру сховища,
обмеження цілісності даних, формати і серверні процедури обробки даних за
викликом або подіями в програмі.
3. Системи на основі багаторівневої архітектури. Багаторівнева
архітектура стала розвитком архітектури клієнт–сервер і в своїй класичній
формі складається з трьох рівнів: нижній рівень – програми клієнтів,
середній рівень – сервер додатків, верхній рівень – віддалений
спеціалізований сервер сховищ даних, виділений для послуг обробки даних і
файлових операцій.
4. Системи на основі Інтернет / Інтранет–технологій. Структура
інформаційної системи має такий вигляд: браузер – сервер програм-сервер
сховищ даних – сервер динамічних сторінок – web-сервер.
Класифікація інформаційних систем за способом організації
архітектури представлена на рисунку 1.2.
Рисунок 1.2 – Класифікація інформаційних систем за способом організації
архітектури
13
За способами організації зберігання даних виділяють ієрархічні,
мережеві та реляційні інформаційні системи [19, с. 56].
1. Ієрархічна модель сховища даних складається з об’єктів із
покажчиками від батьківських об’єктів до нащадків, поєднуючи разом
пов’язану інформацію. Ієрархічні сховища даних можуть бути представлені
як дерево, що складається з різних рівнів. Верхній рівень займає один об’єкт,
другий – об’єкти другого рівня тощо.
2. Мережева модель даних. Мережевий підхід до організації даних є
розширенням ієрархічного. Ця модель базується на використанні
представлення даних у вигляді графа. З погляду теорії графів мережевої
моделі відповідає довільний граф. У ієрархічних структурах запис-нащадок
повинен мати лише одного предка. У мережевий структурі даних нащадок
може мати будь-яку кількість попередників.
3. Реляційна модель даних передбачає, що дані зберігаються у плоских
таблицях. Фактично дані можуть бути організовані й інакше, але користувачі
та додатки, які звертаються до даних, повинні працювати з даними так, якби
вони розміщувалися в таких таблицях. У спрощеному вигляді пласка
таблиця – це таблиця, кожний осередок якої може бути однозначно
ідентифікований вказівкою рядка та стовпця таблиці. Крім того, в одному
стовпці усі осередки повинні містити дані одного простого типу [11, с.
373–374].
Класифікація інформаційних систем за способами організації
зберігання даних представлена на рисунку 1.3.
14
Рисунок 1.3 – Класифікація інформаційних систем за способами організації
зберігання даних
Аналіз класифікації інформаційних систем дозволив виділити важливу
підсистему сховища даних. Сховища даних прийшли на зміну застарілим
способам зберігання даних у вигляді типізованих файлів і дозволили
стандартизувати методи доступу до даних, їх подання, а також зберігання.
Найбільш поширена схема організації інформаційних систем (ІС – далі)
заснована на поділі інформаційної системи на підсистеми програмних
додатків і підсистему сховищ даних.
При аналізі схеми організації інформаційної системи можна назвати
такі елементи системи.
1. Програмний додаток – програмний продукт, що реалізує інтерфейс
взаємодії користувача з інформаційною системою, обробку і подання даних.
Програмне застосування може бути як вебсистемою, так і мобільним
додатком, настільним додатком. При наявній відмінності цих додатків їх
функціонал багато в чому схожий.
15
2. Сховище даних – сукупність програмно-апаратних засобів, що
здійснюють зберігання даних, що забезпечують доступ до них. Сховище
даних є файлова структура для зберігання файлів.
Схема організації ІС, заснованої на сховищі даних, представлена на
рисунку 1.4.
Рисунок 1.4 –Схема організації ІС, заснованої на сховищі даних
Після класифікації ІС, і навіть виділення найпоширенішою схеми її
організації наведемо класифікацію сховищ даних.
За технологією обробки даних сховища поділяються на централізовані
та розподілені. Централізоване сховище зберігається на одній вибраній
16
обчислювальній машині, призначеній сервером сховищ даних. Ця
обчислювальна машина може бути як мейнфрейм з організацією доступу до
неї з використанням терміналів або файловим сервером локальної мережі.
Розподілене сховище даних складається з декількох, можливо, частин,
що перетинаються або навіть дублюють один одного, які зберігаються в
різних ЕОМ обчислювальної мережі. Робота з таким сховищем здійснюється
за допомогою системи керування розподіленим сховищем даних. Основне
завдання систем управління розподіленими сховищами даних полягає у
забезпеченні засобу інтеграції та інкапсуляції локальних сховищ даних, що
розташовуються у деяких вузлах обчислювальної мережі, щоб користувач,
який працює в будь-якому вузлі мережі, мав доступ до всіх цих сховищ
даних як до єдиного сховища [20, с. 107–110].
Можливі однорідні і неоднорідні розподілені сховища даних. В
однорідному кожне локальне сховище даних керується однією і тією ж
системою управління. У неоднорідній системі локальні сховища даних
можуть належати навіть до різних моделей даних. Мережева інтеграція
неоднорідних сховищ даних дуже складна проблема. Багато рішень відомі
теоретично, але поки що не вдається впоратися з головною проблемою:
недостатньою ефективністю інтегрованих систем. Успішніше вирішується
проміжне завдання – інтеграція неоднорідних SQL-орієнтованих систем.
Цьому значною мірою сприяє стандартизація мови SQL.
Прикладом розподіленого сховища даних може бути System R. У цій
системі розробники прикладних програм і кінцеві користувачі залишаються
серед мови SQL. Можливість використання SQL ґрунтується на забезпеченні
System R прозорості розташування даних. Система автоматично виявляє
поточне розташування об’єктів даних, що згадуються в запиті користувача;
одна й та ж прикладна програма, що включає пропозиції SQL, може бути
виконана в різних вузлах мережі. При цьому в кожному вузлі мережі на етапі
компіляції запиту вибирається найбільш оптимальний план виконання запиту
відповідно до розташування даних у розподіленій системі.
17
Завдання побудови оптимального плану розташування даних серед
вузлів розподіленого сховища даних вирішувалося і вирішується багатьма
відомими вченими. Слід зазначити високе поширення структурованих
сховищ даних.
За способом доступу сховища даних поділяються на сховища з
локальним і мережним доступом. Для всіх сучасних сховищ даних можна
організувати мережевий доступ з розрахованим на багато користувачів
режимом роботи.
Централізовані сховища даних із мережним доступом можуть мати
таку архітектуру, яка представлена на рисунку 1.5:
 файл-сервер;
 клієнт-сервер сховища даних;
 «тонкий клієнт» – сервер додатків – сервер сховищ даних
(трирівнева архітектура).
Рисунок 1.5 –Архітектура централізованого сховища даних
Файл-сервер. Архітектура файл-сервер розглядає призначення однієї з
обчислювальних машин мережі як файловий сервер. На цьому комп’ютері
18
встановлюється операційна система для виділеного сервера. На ньому
зберігається спільно використовуване сховище даних у вигляді одного файлу
або групи файлів. Усі інші комп’ютери мережі виконують функції робочих
станцій. Файли сховища даних відповідно до запитів користувача
передаються на робочі станції, де й проводиться обробка інформації [15,
с. 44].
Історично це одна з перших архітектур організації централізованих
сховищ даних. Передача файлів на робочі станції, їх обробка, а також
подальше збереження торкаються проблеми спільного доступу до даних,
контролю їх версій, внесених змін. При великій інтенсивності доступу до
одних і тих самих даних продуктивність інформаційної системи падає. Схема
організації локальної мережі зі сховищем даних як файлового сервера
представлена на рисунку 1.6.
Рисунок 1.6 –Схема організації локальної мережі зі сховищем даних як
файлового сервера
19
Клієнт-сервер. У цій архітектурі на виділеному сервері, який працює
під керуванням серверної операційної системи, встановлюється спеціальне
програмне забезпечення (ПЗ – далі) сховища даних, наприклад від компанії
Microsoft або Oracle. Програмне забезпечення сховища даних поділяється на
дві частини: клієнтську та серверну. Основа роботи клієнт-серверного
сховища даних – використання мови запитів (SQL). Запит мовою SQL,
переданий клієнтом (робочою станцією) серверу, породжує пошук і
вилучення даних на сервері [20, с. 246–248]. Вилучені дані транспортуються
мережею від сервера до клієнта. Тим самим кількість інформації, що
передається по мережі, зменшується в багато разів.
Ця архітектура була поширена через низьку пропускну здатність
мережі Інтернет, відсутність функціональних веббраузерів. Розробка
програмного забезпечення для ІС з архітектурою, що розглядається, велася
переважно на платформах Borland Delphi, Windows Forms тощо. ІС,
побудовані за схемою організації з клієнт-серверним сховищем даних, мали
ряд недоліків, пов’язаних з тим, що основні обчислювальні процеси
виконувались на станціях клієнтів. Адміністратори стикалися з проблемами
версійності програмного забезпечення, необхідністю обов’язкового процесу
інсталяції програмного забезпечення, а також встановленням оновлень.
Схема організації ІС з клієнт-серверним сховищем даних представлена
рисунку 1.7.
20
Рисунок 1.7 – Схема організації ІС з клієнт-серверним сховищем даних
Трирівнева архітектура функціонує в Інтранет та Інтернет мережах.
Клієнтська частина («тонкий клієнт»), що взаємодіє з користувачем,
представляє собою HTML-сторінку у веббраузері чи настільний додаток, що
взаємодіє з веб-сервісами. Уся програмна логіка винесена на сервер додатків,
який забезпечує формування запитів до сховища даних, що передаються на
виконання. Сервер програм може бути вебсервером або спеціалізованою
програмою.
Клієнтські робочі станції виконують функції генерації веб-запитів і
відображення результатів їх виконання. Оскільки, все обчислювальне
навантаження лягає на сервер, то «тонкий клієнт» має мінімальну апаратну
конфігурацію без будь-якої шкоди продуктивності. До цієї архітектури
належать й мобільні програми.
Варто відзначити переваги цієї архітектури:
1. Підтримка кросплатформенності, тому що для роботи інформаційної
системи на клієнтських станціях потрібна наявність програми – браузера.
21
2. Відсутність витрат за адміністрування ІС на клієнтських станціях.
Оскільки дані користувача та налаштування знаходяться на сервері, то при
виході з ладу клієнтської станції немає необхідності переустановки
програмного забезпечення. Достатньо запустити браузер на новому
устаткуванні.
3. Відсутність необхідності технічної підтримки «старих» версій
програмного забезпечення, оскільки програмне забезпечення оновлюється на
сервері централізовано всім користувачів.
4. Спрощення контролю доступу до даних системи, і навіть процесів
ліцензування. Користувач ідентифікується за допомогою логіну і паролю.
Переважне поширення трирівневої архітектури стало можливим зі
зростанням пропускної спроможності мережі Інтернет, доступності
апаратного забезпечення, функціоналом веб-браузерів. Сучасні веб-браузери
надають користувачеві інтерфейс взаємодії з системою, що не поступається
настільному програмному забезпеченню завдяки технологіям AJAX, jQuery
тощо [17, с. 113-116].
Схема організації ІС із трирівневою архітектурою представлена на
рисунку 1.8.
22
Рисунок 1.8 – Схема організації ІС із трирівневою архітектурою
Розглянута класифікація інформаційних систем, сховищ даних з
мережним доступом дозволяє зробити висновок про найбільш поширену
архітектуру зі структурованим сховищем даних, а також виділити її як об’єкт
для вирішення завдання вибору способу підвищення продуктивності
інформаційних систем, що базуються на сховищах даних.
Найбільш поширені архітектури виявлено також на основі проведеного
аналізу операційних систем користувачів системи «Електронний розклад» в
Кременчуцькому національному університеті імені Михайла
Остроградського за вересень 2022 року у сервісі Google Аналітика [19, с. 41].
З проведеного аналізу можна зробити висновок, що сучасні
інформаційні системи мають тенденцію до укрупнення, а також збільшення
часу їх експлуатації. Ефективність ІС розглядається переважно їх
експлуатаційними, а чи не функціональними характеристиками. Задоволення
23
функціональним вимогам (відповідність, повнота, правильність) є лише
необхідною умовою застосування системи [21, с. 33].
Проблеми, типові великих інформаційних систем:
 недостатня надійність;
 зростання експлуатаційних витрат;
 проблема зростання та розвитку;
 стабільність експлуатації.
Експлуатаційні проблеми, пов’язані з недостатньою надійністю,
породжують вимоги:
 система повинна функціонувати без збоїв або з прийнятною їх
кількістю,
 основні функції повинні виконуватися навіть при виході з ладу
окремих елементів системи.
Розроблено безліч підходів щодо задоволення вимог надійності. Один
із них – зменшення числа спеціалізованих елементів системи.
Велика тиражованість універсальних компонентів, наприклад робочих
станцій без спеціалізованого програмного забезпечення дозволяє знизити
витрати, пов’язані з виконанням робіт із заміни елемента системи, що
вийшов з ладу.
Експлуатаційні витрати великих інформаційних систем, їхнє зростання
це складне багатокритеріальне завдання. На етапах розроблення програмного
забезпечення розробники приділяють увагу функціональному наповненню
системи. Для того щоб прискорити запуск ІС іноді приймаються спірні
рішення, пов’язані зі зниженням витрат на розробку окремих вузлів
програмного забезпечення, що спричиняє швидку розробку, але залишає
слабку ланку у всій архітектурі ПЗ.
Зниження експлуатаційних витрат зазвичай досягається за допомогою
централізації вузлів ІС за функціями, що виконуються. У розглянутій раніше
трирівневій архітектурі ІС з мережевим сховищем даних розглядалася
24
проблема централізації вузлів, на яких виконуються основні обчислювальних
дії.
При невеликій кількості вузлів витрати на адміністрування, супровід,
технічне обслуговування, модернізацію та підвищення кваліфікації
персоналу набагато менші, ніж при експлуатації системи, розподіленої за
сотнями або тисячами робочих станцій.
У результаті спостерігається наступний позитивний ефект:
 при внесенні змін до програмного забезпечення модифіковане
програмне забезпечення стає доступним відразу всім користувачам, що
виключає необхідність ведення версій та оновлення програмного
забезпечення на кожному робочому місці;
 кардинально знижуються витрати на придбання (модернізацію) і
встановлення загального програмного забезпечення, тому що воно
встановлюється лише на вузлах обробки, а не на комп’ютерах усіх
користувачів;
 не потрібні спеціальні механізми для створення, ведення та
обслуговування локальних сховищ даних, а також для синхронізації
даних.
Проблеми зростання і розвитку, стабільності експлуатації вирішуються
прєктуванням ІС з використанням компонентного підходу. Це дозволяє
підвищити можливості інформаційної системи у зміні функціоналу
компонентів, вузлів [5, с. 339-341].
Компонентна технологія дозволяє покращити характеристику
оперативності розвитку та містить в основі:
 відділення у програмному забезпеченні прикладної логіки від засобів
загального призначення;
 реалізацію прикладної логіки у вигляді програмних компонентів;
 організацію міжкомпонентної взаємодії на основі стандартних
інтерфейсів.
25
Важливість експлуатаційних характеристик, які часто не враховуються
на етапах розробки програмного забезпечення, дозволяє сформулювати
актуальну проблему підвищення продуктивності інформаційних систем на
основі сховищ даних.
1.2 Альтернативні схеми організації інформаційних систем:
критерії відбору
Аналіз схеми організації інформаційних систем дозволяє
сформулювати завдання ухвалення рішення.
Необхідно з урахуванням вимог до структури інформаційної системи,
заснованої на сховищі даних, вибрати спосіб підвищення продуктивності з
представлених або переконатися у його відсутності.
Представимо завдання вибору способу підвищення продуктивності
інформаційної системи, заснованої на сховищі даних, в ієрархічній формі,
рисунок 1.9.
26
Рисунок 1.9 – Завдання вибору способу підвищення продуктивності
інформаційної системи, заснованої на сховищі даних, в ієрархічній формі
На верхньому рівні знаходиться головне завдання – вибір способу
підвищення продуктивності інформаційної системи, що базується на сховищі
даних. З другого краю рівні – критерії, що характеризують потреби
конкретної інформаційної системи. На третьому рівні представлені
альтернативні способи та підходи до підвищення продуктивності
інформаційної системи [3, с. 55].
Детальний опис кожного з критеріїв:
1. Критерій «Потреба задовольнити високу динаміку зростання» означає,
наскільки важливим є вирішення проблеми зростання даних в
інформаційній системі. До таких систем відносяться комплекси з
активним логуванням, великою кількістю даних, що додаються.
27
2. «Потреба у реструктуризації даних ІС» – критерій, що відображає
можливість перепроєктування структур і способів зберігання даних.
Значення критерію багато в чому залежить від кількості прикладних
програм, що працюють зі сховищем даних ІС. Чим їх більше, тим
більше необхідно внести до них змін для роботи з перепроєктованим
сховищем даних.
3. «Потреба підвищення швидкості обробки запитів на додавання даних»
– критерій, що відображає важливість для інформаційної системи
мінімізації часу виконання запитів додавання і зміна даних. Найчастіше
до таких ІС належать транзакційні системи.
4. «Потреба закупівлі апаратного забезпечення» – критерій, що
відображає можливість підвищення продуктивності ІС за рахунок
придбання нових обчислювальних вузлів або заміни існуючих більш
продуктивними.
5. «Потреба усунення негативного впливу віку системи на
продуктивність» – критерій, важливий для великих інформаційних
систем із тривалим періодом функціонування. При розробці
програмного забезпечення та на ранніх етапах його існування складно
прогнозувати всі негативні ефекти, які можуть виявлятися під час її
тривалої роботи. Поступове зниження продуктивності є загальною
проблемою інформаційних систем, що ростуть, будь-яких масштабів,
побудованих на найсучасніших платформах. Причини можуть бути
різними, і вирішувати цю проблему можна різними способами. Будь-
яка система розвивається – в першу чергу зростає обсяг даних, що
зберігаються в ній. Загальне падіння продуктивності пов’язане з тим,
що функціонал, розроблений кілька років тому, був орієнтований на
дані меншого обсягу. Обсяг даних з часом зростає, і дані вже
потребують інших алгоритмів та підходів до обробки. Аудит – це
стандартний, але дуже об’ємний набір процедур, що дозволяє
28
локалізувати проблеми на різних ділянках інформаційної системи [24,
с. 2].
Великі системи містять безліч табличних структур і великий обсяг
програмного коду, і місце, що породжує проблеми, складно виявити.
Оптимізація інформаційної системи є комплексним заходом, коли
оптимізується вся система цілком – як за рахунок тонкого налаштування
програмної та апаратної частини клієнтів і серверів, так і завдяки зростанню
швидкодії окремих ділянок коду програми. Падіння продуктивності – нерідке
і природне явище, практично неминучий етап циклу життя інформаційних
систем. Аудит цього параметра може бути як разовим, так і регулярним
заходом, а може бути безперервною діяльністю. Важливо, що результатом
цих заходів стає оцінка потенційної та реальної продуктивності ІС,
локалізація «вузьких місць», що знижують швидкодію, та пакет
рекомендацій щодо підвищення ефективності інформаційної системи.
Існує безліч підходів до підвищення продуктивності інформаційної
системи, представлене у вигляді множини:
А= {A1,A2,A3,A4,A5,A6,A7},
де A1 – денормалізація сховища даних (СД – далі). Денормалізація СД –
приведення структури сховища даних у стан, який не відповідає
критеріям нормалізації, що проводиться з метою прискорення операцій
читання даних за рахунок додавання надлишкових даних [1, с. 345].
A2 – оптимальна розстановка індексів СД. Підхід, що ґрунтується на
статистичному аналізі групи запитів на читання інформації та отриманні
оптимального набору індексів таблиць для мінімізації часу виконання
запиту [27,28].
A3 – зміна програмних компонент. Підвищити продуктивність
програмно можна за допомогою оптимізації програмного коду, розробки
нових алгоритмів, реорганізації обчислювальних процесів тощо [1,
с. 345].
29
A4 – рефакторинг табличних структур даних. Підхід, заснований на
вертикальному розподілі таблиць [1, с. 346].
A5 – секціонування даних. Основний зміст секціонування полягає у
фізичному розміщенні частин однієї таблиці з різних файлів, взаємодія з
якими лише на рівні файлової системи та дискового масиву
здійснюється паралельно.
A6 – вертикальне масштабування. Можливість замінювати в існуючій
обчислювальній системі компоненти більш потужними і швидкими у
міру зростання вимог і розвитку технологій. Це найпростіший спосіб
масштабування, тому що не вимагає жодних змін у прикладних
програмах, що працюють у таких системах.
A7 – горизонтальне масштабування. Розбиття системи на більш дрібні
структурні компоненти та рознесення їх по окремих фізичних машинах
або їх групах, або збільшення кількості серверів, що паралельно
виконують одну й ту ж саму функцію. Масштабованість у цьому
контексті означає можливість додавати до системи нові вузли, сервери,
процесори для збільшення загальної продуктивності. Цей спосіб
масштабування може вимагати внесення змін до прикладних програм,
щоб програми могли повною мірою користуватися збільшеною
кількістю ресурсів. Розв’язання задачі вибору способу підвищення
продуктивності може бути отримано методом багатокритеріальної
оцінки альтернатив [5, с. 345].
1.3 Сучасні алгоритми підвищення продуктивності роботи сховища
даних в інформаційних системах
Сучасні інформаційні системи, засновані на сховищі даних,
характеризуються великою кількістю користувачів і високими
обчислювальними потужностями. Для підвищення продуктивності можливі
укрупнені підходи:
30
 зміна в програмній частині;
 зміна в апаратній частині;
 зміна структур зберігання та подання даних.
Підвищити продуктивність програмно можна за допомогою оптимізації
програмного коду, розробки нових алгоритмів, реорганізації обчислювальних
процесів тощо. Підвищення якості програмних комплексів і компонентно
ресурсомістких процесів, вимагає часових і фінансових витрат. При виборі
цього підходу, для вирішення проблеми підвищення продуктивності великих
інформаційних систем, особа, яка приймає рішення, стикається з безліччю
слабоструктурованих завдань, що починаються з аналізу вимог до
інформаційної системи і закінчуються підбором кінцевих виконавців-
розробників.
Для апаратного підвищення продуктивності обчислювальної системи
потрібна зміна архітектури апаратної частини обчислювальних засобів.
Активно застосовується підхід, заснований на переході від однопроцесорних
архітектур до багатопроцесорних обчислювальних систем. Такий підхід
дозволяє підвищити продуктивність за рахунок організації паралельних
процесів і обчислень, а також дозволяє підвищити надійність за рахунок
резервування елементів апаратної складової ІС [12, с. 159].
Існують також підходи, що базуються на вертикальному або
горизонтальному масштабуванні інформаційних систем.
Вертикальне масштабування означає можливість замінювати в
існуючій обчислювальній системі компоненти більш потужними і швидкими
у міру зростання вимог і розвитку технологій. Це найпростіший спосіб
масштабування, тому що не вимагає жодних змін у прикладних програмах,
що працюють у таких системах.
Горизонтальне масштабування означає підвищення продуктивності
інформаційної системи за рахунок зміни структури апаратної частини.
Масштабованість у цьому контексті означає можливість додавати до системи
31
нові вузли, сервери, процесори для збільшення загальної продуктивності.
Цей спосіб масштабування може вимагати внесення змін до прикладних
програм, щоб програми могли повною мірою користуватися збільшеною
кількістю ресурсів.
Процес прийняття рішення щодо застосування методу апаратного
підвищення продуктивності обчислювальної системи складається з
наступних етапів [7, с. 70–71]:
1) визначення переліку вузлів апаратного забезпечення, що негативно
впливає на продуктивність інформаційної системи;
2) визначення вимог, що висуваються до технічних засобів,
обґрунтування складу показників, що характеризують вимоги до
технічних засобів;
3) формування переліку технічних засобів, що випускаються
вітчизняними і зарубіжними фірмами, використання яких дозволить
досягти цілей підвищення продуктивності інформаційної системи;
4) визначення показників якості та функціональних можливостей
технічних засобів у межах сформованого переліку;
5) вибір методу порівняння технічних засобів для визначення найбільш
ефективного;
6) проведення порівняльного аналізу технічних засобів;
7) обґрунтування рекомендацій щодо вибору найбільш ефективних
технічних засобів, що найбільше задовольняють вимогам, що
висуваються;
8) ухвалення рішення про придбання і впровадження обраних технічних
засобів.
Схематичне подання етапів прийняття рішення щодо застосування
методу апаратного підвищення продуктивності ІС представлено на
рисунку 1.10.
32
Рисунок 1.10 – Схематичне подання етапів прийняття рішення щодо
застосування методу апаратного підвищення продуктивності ІС
33
Цей підхід простий у реалізації, але передбачає великі фінансові
витрати на придбання обладнання, забезпечення його працездатності та
енергетичні ресурси, необхідні для експлуатації отриманої апаратної
конфігурації. Зміна структур зберігання і подання даних. Так як більшість
веб-систем, мобільних додатків, настільного програмного забезпечення
використовують для зберігання даних у структурованих сховищах даних,
завдання підвищення продуктивності ІС зводиться до завдання зменшення
середнього часу виконання запитів на читання інформації. Існує кілька
підходів до зменшення середнього часу виконання запитів на читання
інформації до сховища даних, розглянемо їх.
1. Підхід, що ґрунтується на статистичному аналізі групи запитів на
читання інформації та отримання оптимального набору індексів таблиць для
мінімізації часу виконання запиту. Дослідженнями цього підходу займаються
польські вчені Радослав Боронскі та Гжегож Боцевіч. Концепція індексації
таблиць у системах реляційних сховищ даних, на відміну від відомих
підходів, що враховують індексацію за окремими запитами, полягає у
розгляді запитів у вигляді групи [5]. Авторами помічено, що в ІС на етапі
експлуатації формується безліч запитів на читання інформації з відомими
значеннями математичних очікувань ймовірності появи того чи іншого
запиту. Ефективність методу доведена під час обчислювального
експерименту. Концепція підходу представлена на рисунку 1.11.
34
Рисунок 1.11 – Концепція підходу оптимального розміщення індексів
Завдання оптимального розміщення індексів є далеко не новим.
Існують вбудовані в сховище даних програмні компоненти, що збирають
статистику частоти використання атрибутів таблиць у запитах, за допомогою
яких можна визначити набір атрибутів для індексування. Завдання не втрачає
своєї актуальності через необхідність мінімізувати обсяг пам’яті, необхідний
зберігання даних індексу. Також велика кількість індексів вимагає виконання
періодичної реструктуризації через фрагментацію індексів через маніпуляції
з даними у табличних структурах. Реструктуризація індексів також потрібна
при активному додаванні рядків до таблиці.
2. Денормалізація сховища даних – приведення структури сховища
даних у стан, що не відповідає критеріям нормалізації, що проводиться з
метою прискорення операцій читання із сховища за рахунок додавання
надлишкових даних.
Основною метою нормалізації є:
 усунення надмірності при зберіганні даних, що призводить до
збільшення обсягу СД;
35
 виключення необхідності модифікації даних у зв’язкових таблицях
для мінімізації часу та операцій, у межах однієї транзакції. Зростання
кількості операцій маніпулювання даними негативно впливає на розраховану
на багато користувачів роботу сховища даних взаємними блокуваннями і
збільшенням часу відгуку системи.
Мета нормалізації, що розглядається, стосуються транзакційних
додатків, але якщо мінімізація часу відгуку системи є однією з пріоритетних
вимог, то можливо на шкоду нормалізації використовувати надлишкові дані.
У роботі сховища даних, як і в роботі будь-якої програми на ЕОМ,
найбільш витратними за часом є завдання зчитування даних з дискових
накопичувачів оперативної пам’яті для подальшої обробки.
Другим за часовими витратами йдуть обчислювальні процеси,
пов’язані з перебором рядків під час виконання запитів читання інформації.
Найбільш явно це простежується під час виконання запитів до таблиці, яка
має багато атрибутів – зовнішніх ключів, з відповідними потенційними
ключами в таблицях-довідниках. Виконання запиту до таких табличних
структур вимагатиме зчитування і підставлення значень атрибутів із таблиць-
довідників відповідно до зовнішніх потенційних ключів. Варто зазначити, що
потенційними ключами є первинні ключі таблиць, за допомогою яких
автоматично будується кластерний індекс, позитивно впливаючи на
тимчасове виконання запиту.
Обчислювально-трудомістких з’єднань таблиць можна уникнути, якщо
використовувати денормалізацію таблиць [19, с. 101].
Існують деякі правила, що дозволяють вважати денормалізовані з
погляду транзакційної обробки таблиці «нормалізованими» згідно з
правилами побудови таблиць для сховищ даних.
В аналітичній обробці вважаються нормалізованими дві схеми:
1) «сніжинка»;
2) «зірка».
36
В обох схемах центральним елементом є таблиця фактів, що містить ті
чи інші відомості. У разі транзакційного сховища даних, кожна сутність
розподілена за кількома таблицями після процедури нормалізації. У разі
аналітичного сховища даних відомості про сутність містяться в одному рядку
таблиці фактів і не вимагають об’єднання таблиць при виконанні запиту на
читання інформації. На рисунку 1.12 наведено приклад аналітичної таблиці
системи «Електронний розклад» Кременчуцького національного
університету імені Михайла Остроградського.
Рисунок 1.12 – Приклад аналітичної таблиці системи «Електронний
розклад»
37
З представленої діаграми цілісності видно, що таблиця OperationLog,
яка виконує функції логування дій користувачів системи, пов’язана
відносинами з набором таблиць: GroupStudent, Classroom, Authorise,
WeekType, Discipline, Weeks, Teacher.
При виконанні запиту читання інформації сховищу необхідно буде
виконати операцію об’єднання 8 таблиць. Ця операція є ресурсомісткою у
плані процесорного часу.
Після застосування підходу, що базується на денормалізації, атрибути
таблиці, які були зовнішніми ключами, будуть замінені фактичними
значеннями.
Замість важкого з’єднання між вісьма таблицями сховищу дістається
пряма робота з однією таблицею логування.
При денормалізації таблиці, які називаються вимірами, також
з’єднуються з таблицею фактів. Якщо таблиця фактів посилається на таблиці-
вимірювання, що мають посилання на інші виміри (виміри другого рівня та
вище), то така схема називається «сніжинка».
Схема, у якій таблиця фактів посилається лише на виміри, які не мають
другого рівня, вона називається «зірка». Число таблиць вимірювань
відповідає числу «променів» у зірці. Схема «зірка» повністю виключає
ієрархію вимірів і необхідність з’єднання відповідних таблиць в одному
запиті, представлена на рисунку 1.13.
38
Рисунок 1.13 – Схема денормалізації «Зірка»
Зворотною стороною денормалізації завжди є надмірність, що є
причиною збільшення розміру сховища даних, як у випадку транзакційних,
так і аналітичних додатків.
Універсальних рекомендацій щодо денормалізації не існує, це завжди
компроміс між розміром сховища даних і часом виконання запитів. Якщо
вичерпані всі можливі способи оптимізації запитів і фізичного зберігання на
даній схемі сховища даних, слід розглянути можливість її подальшої
денормалізації, що, однак, не є єдиним шляхом вирішення проблем
продуктивності системи. Найбільш поширений спосіб – організація на основі
сховища даних ще більш агрегованих таблиць (вітрин) і багатовимірних
кубів, які й будуть служити сховищами даних для запитів користувачів.
39
3. Секціонування даних. Основний зміст секціонування полягає у
фізичному розміщенні частин однієї таблиці з різних файлів, взаємодія з
якими лише на рівні файлової системи і дискового масиву здійснюється
паралельно [14, с. 20-27].
Секціонування або партикування представляє собою поділ однієї
таблиці на кілька секцій (розділів, partitions) за заданою в одній або кількох
колонках ознакою. Для таблиці логування пріоритетними є операції
додавання даних. Таблиця може зростати досить у високому темпі за рахунок
активних дій користувачів.
У межах життєвого циклу інформаційної системи таблиці, в яку
активно додаються дані, можуть збільшитися в десятки разів. Операції
додавання даних викликають операцію перебудови індексів. Якщо для
функціонування інформаційної системи необхідні дані лише за останній рік
або будь-який інший фіксований проміжок часу, то у межах секціонування
необхідно розділити таблиці на основі обраної ознаки поділу, наприклад,
дати. У системі «Електронний розклад», де розглядається, більшість запитів
на читання інформації використовує тільки поточний семестр, і в поодиноких
випадках минулий. Інші дані про розклад занять зберігаються у системі, але
частих звернень до них немає.
У цьому випадку програми оперативного контуру, що додають,
змінюють та видаляють дані працюють не з єдиним об’ємним файлом
таблиці, а з одним файлом невеликого розміру, що зберігає дані певної секції.
Це суттєво зменшує кількість необхідних операцій введення / виведення.
Схема секціонування таблиці представлена на рисунку 1.14.
40
Рисунок 1.14 – Схема секціонування таблиці
Внутрішня схема розташування даних секціонованої таблиці
інкапсульована від користувача. Запити звернені до вихідної таблиці, а
сховище даних автоматично визначає план виконання запиту. Внутрішній
механізм підтримки секціонування в Microsoft SQL Server реалізований за
допомогою функцій і схем секціонування, в PostgreSQL через успадкування.
Якщо сховище даних не підтримує явне секціонування, то в багатьох
випадках буде працювати метод з використанням безлічі однотипних таблиць
і виду, що горизонтально об’єднує їх (view).
Основний недолік такого підходу – нижчий рівень абстракції та, як
наслідок, дещо більша залежність додатків від фізичного проєктування. Так,
додаткові операції з підтримки секцій (злиття, поділ) повинні проводитися не
самим сховищем даних у термінах відповідних команд, а адміністратором за
допомогою безлічі команд SQL. Крім того, якщо сховище даних не підтримує
41
механізм тригерів для видів, то безпосередні операції вставки, модифікації та
видалення можуть виявитися неможливими, додатку потрібно самостійно
вибирати відповідну таблицю нижче.
4. Рефакторинг табличних структур, який заснований на їхньому
вертикальному поділі таблиць на безліч атрибутів. Питання рефакторингу
табличних структур і його доцільності у науковому співтоваристві
порушується досить часто, особливо для систем оперативної обробки
транзакцій (OLTP). В основі підходу до поділу є спроба об’єднати два
традиційні підходи до зберігання даних:
 вертикальне;
 горизонтальне.
При вертикальному розташуванні даних таблиць значення атрибутів
зберігаються в окремих блоках даних. При горизонтальному в блоках даних
зберігаються рядки таблиць. Переваги вертикального розташування
полягають у відсутності необхідності сканувати дані, які беруть участь у
запиті читання даних. В оперативну пам’ять сховища даних вибираються
необхідні для виконання запиту атрибути. Основним недоліком є тривале
виконання запитів на додавання та модифікацію даних, так як при додаванні
рядка з атрибутів N потрібно N кількість позиціонувань головки жорсткого
диска.
Переваги і недоліки рядкового розташування даних є інверсією переваг
і недоліків вертикального розташування. Сховища даних з вертикальним
розташуванням найчастіше використовуються в системах інтерактивної
аналітичної обробки (OLAP) через невелику кількість запитів на додавання
даних. По рядкове розташування даних використовується у сховищах даних
систем оперативної обробки транзакцій (OLTP), через велику кількість
запитів додавання і модифікацію даних [40]. Спроби взяти найкраще від двох
принципово різних способів зберігання даних ведуться і сьогодні. Компанія
Microsoft, починаючи з версії MS SQL 2016, активно розробляє та
42
впроваджує технологію колонкових індексів. Teradata – американська
корпорація, що спеціалізується на розробці та постачанні апаратно-
програмних комплексів для обробки та аналізу даних, з 2014 року розробляє і
впроваджує технології гібридного зберігання даних табличних структур [42].
Єдиного підходу до вертикального розподілу даних немає. Усі методики
зводяться до рекомендацій для проєктувальників сховищ даних, чіткої
методики поділу досліджуваної таблиці на дочірні немає [29].
1.4 Висновки до розділу 1
1. Проаналізовано типові структури інформаційних систем, їх переваги,
недоліки, поширення. Виявлено, що основною архітектурою інформаційних
систем є трирівнева архітектура з «тонким клієнтом» – браузером, веб-
сервером і сховищем даних.
2. Систематизовано методи підвищення продуктивності інформаційних
систем на основі сховищ даних. Виявлено негативний вплив віку
інформаційної системи на продуктивність.
3. Проведено аналіз методів підвищення продуктивності сховищ даних,
за результатами якого було виявлено їх переваги і недоліки. Обґрунтовано
вибір методу зберігання даних на основі вертикально розділених таблиць.
43
РОЗДІЛ 2
РОЗРОБКА МЕТОДИКИ ОПТИМІЗАЦІЇ МОДЕЛІ СХОВИЩА ДАНИХ
НА БАЗІ КЛАСТЕРИЗАЦІЇ АТРИБУТІВ
2.1 Визначення предметної області підвищення продуктивності
сховища даних
Оперативна взаємодія з користувачем, мінімізація часу реакції
системи – набір вимог, які ставляться перед більшістю інформаційних
систем, заснованих на сховищах даних. Виконання вимог залежить не тільки
від апаратної складової, що включає серверне обладнання та лінії зв’язку, але
й від реалізації програмних компонентів, серед яких програмний додаток, що
реалізується із застосуванням веб-технологій і сховища даних. Найбільш
затратними за часом є дискові операції, пов’язані з позиціонуванням голівки,
що зчитує, а також часом зчитування даних, що пов’язане з операціями
перериваннями. Часові витрати на виконання цих операцій у свою чергу
залежать від моделі даних, способи її фізичного розміщення на жорстких
дисках. Реляційне сховище даних – це сукупність даних і зв’язків між ними.
Дані організовані у вигляді табличних структур і наборів значень атрибутів –
рядків. Табличні структури містять інформацію про об’єкт предметної
області, які розміщені у сховищах даних. Кожен стовпець табличної
структури містить дані певного типу, відповідного типу атрибута стовпця.
Перетин стовпчика і рядка містить значення атрибута. Рядок табличної
структури містить набір пов’язаних значень, що характеризує об’єкт
предметної області. Первинний ключ – значення чи набір значень атрибутів
однозначно характеризує рядок табличної структури. Зв’язки між
табличними структурами реалізуються за допомогою з’єднання потенційних
і зовнішніх ключів. До цих даних можна отримати доступ через різні запити,
і при цьому реорганізовувати таблиці не потрібно [23, с.100].
44
Одним з основних принципів щодо структури фізичного запису є
збереження змісту логічного записи. Фізична запис – сукупність пов’язаних
елементів даних, що відповідають одній чи декільком логічним записам.
Фізичний запис складається з двох частин: службової частини та
інформаційної.
Службова частина фізичного запису використовується сховищем даних
для ідентифікації запису, завдання її типу, зберігання ознаки видалення,
зберігання покажчиків на елементи запису, ідентифікатора довжини запису,
встановлення структурних асоціацій між записами, для кодування значень
елементів. Програми користувача не мають доступу до службової частини
фізичного запису. Поля інформаційної частини фізичного запису містять
значення елементів даних. Існує кілька способів розміщення елементів даних
у фізичному записі.
Види форматів фізичних записів.
1. Позиційний спосіб організації фізичних записів. У кожному записі
порядок прямування елементів однаковий, тип елементів не вказується,
зберігається лише значення. Поля мають фіксовану довжину. Значення
елемента в кожному екземплярі запису з’являється з однієї і тієї ж позиції,
визначеної в описі структури сховища даних. Усі записи мають однакову
довжину. При такому форматі запису можливе застосування ефективних
алгоритмів пошуку (двійковий метод, метод золотого перерізу тощо), але
пам’ять не раціонально використовується. Також одним з переваг
позиційного способу організації фізичних записів є відсутність тимчасових
витрат на визначення адреси кінця одного запису та початку наступного.
Якщо дані мають меншу довжину, ніж розмір поля запису, то вирівнювання
ліворуч або праворуч, і вільні місця заповнюються пробілами. Розмір поля
визначається на етапі проєктування структури сховища даних відповідно до
можливих значень атрибутів предметної області. Кількість вільних місць
може бути скорочена за допомогою роздільників або індексного методу.
45
2. Спосіб зберігання записів із роздільником. Запис має поля змінної
довжини і отже сам запис має змінну довжину. Відповідно до способу
зберігання необхідно вибрати певний символ роздільника, який ніде більше
не використовується при організації файлів сховища даних. Наприклад,
символ #. При такому способі організації записів, що зберігаються, пам’ять
витрачається економно, але неможливе застосування швидких алгоритмів
пошуку даних. Досягається виграш у пам’яті, але програш у швидкодії.
3. Індексний спосіб організації фізичних записів. При даному способі
визначення початку значень елементів записів використовується масив
покажчиків, розміщений у службовій частині запису. Аналогічно способу
зберігання з роздільником індексний спосіб більш економно витрачає
пам’ять, але не дозволяє для пошуку даних використовувати ефективні
алгоритми пошуку. Необхідність окрім зчитування інформаційної частини
запису, ще й службового та її обробка, негативно позначається на швидкість
виконання запитів на читання даних.
4. Спосіб зберігання з описами. Цей спосіб ефективний, якщо запис
містить багато елементів, значення яких відсутні і необхідно зберігати тільки
елементи з відомими значеннями.
З розглянутих способів, в останніх трьох пам’ять використовується
більш економно, особливо у разі відсутності заповнення деяких полів, на
пошук потрібної інформації витрачається більше часу.
Кластеризація записів – об’єднання записів різного типу у фізичні
групи, що дозволяє якомога ефективніше використовувати перевагу
послідовного розміщення даних. Кластеризація – розміщення пов’язаних
даних поблизу один від одного з метою підвищення ефективності доступу.
При логічній кластеризації певні типи елементів даних поєднуються у
записи. При фізичній кластеризації екземпляри записів одного або різних
типів об’єднуються і розміщуються в один блок, одну область або на один
пристрій. Завдання кластеризації полягає у визначенні того, яким чином для
заданої моделі даних необхідно зберігати записи сховища даних для того,
46
щоб для типових експлуатаційних навантажень мінімізувати час доступу,
тобто дані, що найчастіше беруть участь в операціях пошуку і
маніпулювання даними, об’єднуються і до них в першу чергу здійснюється
звернення. Загалом оптимальну кластеризацію важко здійснити для складних
інтегрованих сховищ даних, де дані, до яких здійснюється звернення за
допомогою різних прикладних програм, перекриваються, і легко знайти
компроміс між послідовними і довільними методами пошуку. Важливим
поняттям при розгляді питання фізичної організації сховищ даних є поняття
блоку.
Блок – мінімальний адресований елемент зовнішньої пам’яті, за
допомогою якого здійснюється обмін інформацією між оперативною та
зовнішньою пам’яттю. Блоковий принцип представлення даних є основним
для операційної системи та містить цілий набір переваг, найбільш важливим
з яких є фіксований розмір даних, що переміщуються по шинах даних. Обмін
даних зовнішньої пам’яті з оперативною пам’яттю здійснюється блоками.
Запис і читання блоків здійснюється через буферну пам’ять оперативної
пам’яті. Для організації кожного файлу сховища даних, залежно від його
розміру зовнішньої пам’яті, відділяється від одного до N блоків, де
розміщуються записи. Відповідно до блокового принципу зберігання даних
можливі наступні варіанти розміщення:
 в одному блоці можуть розміститися всі записи;
 у кількох блоках – один запис;
 або в одному блоці – один запис.
Від вибраного варіанта розміщення залежить час зчитування та запису
елементів файлу. Кожен байт у блоці має власний номер. Номер байта блоку,
з якого починається запис, визначає відносну адресу запису в блоці, тобто
адресу запису дорівнює номеру блоку плюс відносна адреса в блоці
(послідовний доступ), або номер блоку і значення ключа (тут поєднання
послідовного і прямого методів доступу). Записи в блоках розміщуються
47
щільно, без проміжків, послідовно одна за одною. У блоці частина пам’яті
відводиться під службову інформацію: відносну адресу вільних ділянок
пам’яті, покажчики наступного блоку тощо. Для зберігання даних, що
надходять, які повинні розміщуватися в одному блоці, заповненому вже
повністю, виділяється додатковий блок пам’яті в області переповнення
запису, організованої у вигляді одного блоку, де записи зв’язуються
покажчиками в один ланцюг. Зазвичай прагнуть область переповнення
обмежити, тому що час пошуку інформації в області переповнення сильно
збільшується. Тому, як досягається межа області переповнення, проводять
реорганізацію файлу сховища даних. Розмір блоку дуже впливає на
продуктивність сховища даних – при великих розмірах швидкість операцій
читання / запису зростає, особливо це характерно для повних переглядів
таблиць і операцій інтенсивного завантаження даних, проте зростають
накладні витрати на зберігання та знижується ефективність індексних
переглядів [58].
Менший розмір блоку дозволяє більш економно витрачати пам’ять.
Довгі блоки краще використовувати для великих об’єктів: повнотекстові
фрагменти, мультимедіа об’єкти, довгі рядки тощо. Короткі блоки краще
підходять для значень числових типів, коротких рядків, значень дати та часу.
Важливо також враховувати розмір блоку операційної системи, він повинен
бути кратний розмір блоку сховища даних. Малий розмір блоку краще
підходить для систем оперативної обробки транзакцій, тому що, якщо сервер
блокує дані на рівні блоків, це дозволяє більшій кількості користувачів
працювати, не заважаючи один одному. У системах підтримки прийняття
рішень, для яких більш критичним є не загальна пропускна здатність, а
кількість транзакцій за одиницю часу), а середній час відгуку, більший блок є
кращим.
Перекомпонування фізичних блоків даних – ресурсомістка операція,
яка тягне за собою операції перебудови індексів. Тому вибір типу атрибуту,
кількості дискового простору, займаного елементом актуальна
48
багатокритеріальна задача, яку проєктувальники сховищ даних часто не
беруть до уваги і як наслідок вибирають типи даних з невиправдано високим
верхнім кордоном [16, с. 143].
Для кожного файлу блоки пронумеровані, і система визначає потрібний
файл на ім’я файлу та за номером блоку. Таким чином, на швидкість пошуку
впливають: обсяг блоку в байтах, обсяг файлу, кількість записів у блоці
файлу, кількість записів у блоці індексу, кількість блоків у файлі, частка
резервної частини блоку, кількість полів у запису, розмір запису в байтах,
довжина ключового поля у записі. Відповідно до мети – зменшенням часу
виконання запитів на читання інформації зі сховища даних у методиках
розглядається позиційний спосіб організації записів, що зберігаються, що
забезпечує високу швидкість пошуку за рахунок фіксованої довжини
зберігаються в блоках фізичних записів.
Запропоновані методики спрямовані на оптимізацію розміщення даних
таблиць сховища даних і складаються з наступних вихідних даних і
елементів базових множин. Типи даних інформаційної системи. Тип даних
деякого об’єкта – це властивість цих даних, яке визначає, які значення можна
зберігати у цьому об’єкті і які операції з цими значеннями можна
виконувати. У сучасних сховищах даних застосовуються такі типи даних:
 символічний (текстовий);
 числовий;
 логічний;
 тимчасовий;
 спеціалізований.
На вибір типів даних для інформаційної системи впливає думка
експерта у сфері, з якою пов’язана інформаційна система. Рядкові типи даних
з фіксованою та змінною довжиною впливають на швидкість виконання
запиту. Індексування рядковими полями відбувається значно швидше, якщо
вони мають фіксовану довжину. Типи даних інформаційних систем
49
включають різні підтипи, які відрізняються розмірністю, але зберігають всі
властивості «батьківського» типу. Наприклад, тип даних – рядковий. Підтипи
рядкового типу: nchar(10), varchar(255) тощо.
Атрибути даних інформаційної системи. Атрибут є властивістю, що
описує сутність. Атрибути відповідають типу даних інформаційних систем.
Всі дані, що зберігаються в атрибуті, повинні мати однаковий тип і мати
однакові властивості. Об’єм пам’яті, який займає атрибут. Кожен підтип
даних характеризується обсягом пам’яті, необхідним зберігання екземпляра.
Проблема вибору оптимального підтипу атрибута пов’язана з
швидкодією інформаційної системи і реляційного сховища даних, що працює
з нею.
Індекси. У сховищах даних найбільшого поширення набули індекси
двох типів: кластерні та некластерні. Однією з особливостей кластерного
індексу є те, що один елемент індексу відповідає сторінці даних. Сторінка є
фізичним блоком для зберігання даних. Після того, як сервер визначить
сторінку, він знаходить на сторінці потрібний запис. Кластерний індекс
реалізує механізм індексно-послідовного доступу, причому індекс
побудований як бінарного дерева. Після того, як сервер визначить сторінку,
він знаходить на сторінці потрібний запис. Оскільки кластерний індекс
дозволяє вийти перший запис результату і організувати наступний перебір
таблиці у пошуках інших записів без повернення рівень індексу, кластерні
індекси відмінно підходять для вибірки інтервалів даних. До цієї категорії
належать зовнішні ключі, списки імен і будь-які інші сукупності даних із
послідовними ключами. Завдяки структурі кластерних індексів пошук у них
зазвичай виконується швидше, ніж під час вибірки довільних записів для
відповідних некластерних індексів. Але це умовне правило, залежить від
кількості покажчиків, необхідні індексу кожного типу, і навіть від їх ширини.
Іноді кластерний індекс працює значно швидше, а іноді взагалі не дає
переваги у швидкості, хоча для більшості запитів кластерні індекси
працюють швидше за некластерні. Некластерний індекс реалізує механізм
50
індексно-довільного методу доступу. Його найважливіша особливість у тому,
що один елемент індексу охоплює однин запис. Кожному запису у таблиці
призначається ідентифікатор. Оскільки в некластерному індексі кожен
покажчик відповідає одному запису, а також тому, що їх покажчики мають
більший розмір, ніж кластерні індекси, оскільки містять ідентифікатор
запису, а не просто ідентифікатор сторінки, некластерні індекси займають
набагато більше місця. Для підвищення швидкодії кластерний індекс слід
створювати раніше за некластерні. Створення кластерних індексів вимагає
фізичного сортування записів, а некластерні індекси містять покажчики на
сторінки і записи, які доводиться модифікувати під час переміщення записів.
При створенні кластерного індексу знадобиться вільне місце у сховищі даних
в обсязі відсортованої копії з індексом, або приблизно 120-150% обсягу
таблиці.
Зберігання процедур і функцій. Процедура, що зберігається, – це об’єкт
сховища даних, набір відкомпільованих команд – підпрограма, що працює на
сервері. Оскільки процедура, що зберігається, проходить попередню
компіляцію і оптимізацію, вона більш ефективна, ніж аналогічний набір
команд, що виконується з клієнта. Збережена процедура викликається на
ім’я, як програмний модуль, і може приймати параметри і повертати
результати. У код процедури, що зберігається, можуть використовуватися не
тільки операції вилучення і модифікації даних, але й логіка розгалуження,
змінні та інші мовні інструкції, які роблять процедури, що зберігаються
потужним засобом реалізації логіки обробки. Збережені процедури можуть
бути чотирьох типів:
 системні,
 локальні,
 тимчасові,
 видалені.
51
Ця класифікація з області видимості. Системні процедури зберігаються
у сховищі даних і починаються зі спеціалізованого префікса. Для зміни
системної процедури, що зберігається, потрібно зробити її копію, зберегти
оригінальну процедуру під іншим ім’ям. Локальні процедури, що
зберігаються, створюються в користувацьких сховищах даних. Якщо
процедура створюється з ім’ям # або ##, то створюється тимчасова
процедура, що зберігається і поміщається в окреме сховище даних.
Процедури, що починаються з ## – глобальні, вони видно будь-якої сесії
зв’язку з цим сервером. Процедури з одним # – локальні і видно лише із
з’єднання, в якому вони створені. Коли з’єднання, в якому було створено
процедуру, закрито, процедура автоматично знищується. Видалені процедури
можуть викликатися не лише з поточного сервера, з яким клієнтська
програма встановила з’єднання. При цьому поточний сервер є проміжною
ланкою [15, с. 143-147].
Є ще один тип процедур, що зберігаються – розширені збережені
процедури. Вони принципово відрізняються від перелічених. Це файли
бібліотек DLL, як правило, написані високорівневою мовою програмування, і
називаються збереженими тільки тому, що ім’я зберігається в сховищі даних.
Самі DLL зберігаються як файли у відповідному каталозі операційної
системи.
Тригери. Тригер – це об’єкт сховища даних, що є спеціальним типом
процедури, що зберігається, яку, наприклад, SQL Server виконує при
операціях в даній таблиці. Тригери виконують після застосування правил,
значень за умовчанням і забезпечують обмеження цілісності на рівні рядків,
забезпечує цілісність посилань у сховище даних. Виконання будь-якої
команди модифікації призводить до спрацьовування тригера.
Група запитів. Запити до сховища даних формуються за допомогою
мови SQL і повідомляють сховищу даних про необхідність виконання певної
дії. Наприклад, запити SQL дозволяють:
 створити таблицю;
52
 отримувати підсумкові дані;
 додавати дані;
 видаляти дані;
 оновлювати (змінювати) дані;
 захищати дані.
Група запитів до сховища даних містить відомості про атрибути
таблиць для кожного запиту на вибірку інформації, а також частоту появи
кожного запиту за обраний період часу. В основі методики лежить
статистичний аналіз групи запитів, які використовує прикладне програмне
забезпечення під час роботи зі сховищем даних. Життєвий цикл будь-якої
стабільної інформаційної системи, яка зберігає дані в реляційному сховищі
даних, на певному етапі дозволяє сформувати безліч типових запитів на
читання інформації.
2.2 Алгоритмічна модель субоптимального розподілу таблиць на
базі кластерного аналізу груп запитів в інформаційній системі
Для вирішення задачі розроблено методику, засновану на кластерному
аналізі групи запитів до сховища даних. Алгоритм альфа-
квазіеквівалентності. Евристичний алгоритм складається з наступних
етапів [45]:
1) Розглянемо бінарне нечітке відношення R на множині ATR= {atr1,
atr2, ... atrTS}, задане у вигляді функції приналежності R={����(��������1, ��������2)|��������1,
��������2 ∈ ������}, де
53
Функція приналежності визначається як нормована за сумою запитів
кількість парних зустрічей атрибутів ��������1, ��������2
Відношення R має наступні властивості:
1. Симетричні
Алгоритм автоматичної кластеризації вимагає, щоб відношення мало
властивість (max – min) транзитивності:
(max – min) транзитивним замиканням бінарного нечіткого відношення
R на множині ������, де card (������)=TS називається бінарне нечітке
відношення R на множині ������, що визначається наступним чином
Де відношення RTS визначається рекурсивно:
2) Після отримання бінарного нечіткого транзитивного відношення Ř,
обчислюються α – рівні, α ∈ [0,1], виділяються кластери Al, l ∈ відповідно до
правила: якщо ��Ř(��������1, ��������2), для деяких , то об'єкти належать кластеру.
3) З отриманої ієрархії розбиття вибирається розбиття, ефективність
якого оцінюється за допомогою виведеної в рамках дослідження цільової
функції, що представлена на рисунку 2.1. Атрибути, що належать кластеру,
виділяються до окремої дочірньої таблиці [1, с. 367].
54
Рисунок 2.1 – Цільова функція
Обчислення за методикою таблиці з 5 атрибутів.
1) Параметр TS=5, характеризує кількість стовпців таблиці.
2) Опис полів подано у таблиці 2.1.
Таблиця 2.1 − Опис полів таблиці
Номер по порядку Найменування стовпця Тип зберігання даних
1. Id Bigint
2. Attr1 nchar(10)
3. Attr2 nchar(10)
4. Attr3 nchar(10)
5. KeyForSearch nchar(10)
3. Множинність типів даних атрибутів DBT, які підтримуються
обраним сховищем даних MS SQL 2019. Задано вектором, що характеризує
дисковий простір, що займається типом даних, в байтах DBT={4, 8, 20}
[17, с. 267]. Кількість типів даних сховища зменшено для компактності
55
викладу. Багато типів даних сховища MS SQL 2019 може бути представлене
у вигляді таблиці 2.2.
Таблиця 2.2 – Множинність типи даних сховища MS SQL 2019
Місце, що займає на
Номер по порядку Найменування типу даних дисковому просторі в
байтах
1. int 4
2. bigint 8
3. nchar(10) 20
4. Набір атрибутів (стовпців таблиці) представлено вигляді таблиці 2.3.
Таблиця 2.3 − Набір атрибутів (стовпців таблиці) TA
DBT1 DBT2 DBT3
А1 0 1 0
А2 0 0 1
А3 0 0 1
А4 0 0 1
А5 0 0 1
5. Множинність, що представляє групу запитів отримання інформації зі
сховища даних, що складається з 3 елементів. Характеристики запитів подано
у вигляді таблиці 2.4.
56
Таблиця 2.4 – Характеристики запитів
Кількість запитів, що Бінарні вектор
Номер по порядку надійшли на сервер за атрибути, що беруть
вибраний період часу участь у запиті
1. 20 <0,0,1,1,0,0>
2. 5 <1,0,1,1,1>
3. 10 <0,0,1,1,1>
На основі множинних запитів побудовано бінарне відношення.
Елемент відношення дорівнює частоті появи пари елементів у групі запитів.
Подано на рисунку 2.2.
Рисунок 2.2 – Бінарне відношення на основі множинних запитів
Після застосування нормалізації за максимальним елементом
відношення отримали бінарне нечітке відношення, представлене на
рисунку 2.3.
57
Рисунок 2.3 – Нечітке бінарне відношення
Згідно з методикою отримано транзитивне замикання нечіткого
бінарного відношення. Результат виконання операції композиції двох
нечітких відношень представлено на рисунку 2.4.
Рисунок 2.4 – Композиція нечітких бінарних відношень
Транзитивне замикання нечіткого бінарного відношення представлено
рисунку 2.5.
58
Рисунок 2.5. – Транзитивне замикання нечіткого бінарного відношення
Результат обчислення альфа рівнів і кластеризації представлений у
вигляді таблиці 2.5.
Таблиця 2.5 – Результати обчислення альфа рівнів і кластеризації
Значення цільової
Елементи функції (Кількість
Значення альфа-рівня
альфа-рівня блоків, які було зчитано
зі сховища)
{A3}, {A1, A2, A4, A5} 1 273000
{A2, A3}, {A1, A4, A5} 0,571 189000
{ A1}, {A2, A3, A4, A5} 0,429 237000
{A1, A2, A3, A4, A5} 0,143 252000
Отже, табличну структуру необхідно розділити на дві дочірні, які
складаються з атрибутів {A2, A3}, {A1, A4, A5}. Алгоритм застосування
методики представлений на рисунку 2.5.
59
Рисунок 2.6 – Алгоритм застосування методики
60
2.3 Представлення методики субоптимальної реструктуризації
табличних структур сховища даних на основі багатомодального
розподілу атрибутів
Для вирішення завдання розроблено методику, засновану на
багатомодальному розподілі атрибутів досліджуваної таблиці за критерієм
появи їх у групі запитів на читання інформації. Для отримання оптимального
розбиття досліджуваної таблиці з числом атрибутів дорівнює [14, с. 56].
1. Отримати для кожного атрибута значення частоти його появи в групі
запитів до сховища даних. Вектор частот появи атрибутів досліджуваної
таблиці групи запитів Q, де FTA={ftaifta|ifta= ̅1̅,̅T ̅S ̅},
Графічний приклад розподілу атрибутів за частотою їх появи групи
запитів представлений на рисунку 2.7.
61
Рисунок 2.7 – Графічний приклад розподілу атрибутів за частотою їх
появи у групі запитів
2. Відсортувати атрибути за частотою їх появи групи запитів.
3. Сформувати групи атрибутів із однаковою частотою. Отримаємо
розбиття кінцевої множини. FTA ́. GF ́ = {gf1, ... gf́bń}, де gf́1Ս… Ս
Графічний приклад сортування та групування атрибутів за частотою їх
появи в групі запитів представлений на рисунку 2.8.
62
Рисунок 2.8 – Графічний приклад сортування і групування атрибутів за
частотою їх появи у групі запитів
4. Отримати розбиття множини груп атрибутів. Отримаємо розбиття
кінцевої множини GF. GF ́ = {gf́1, ... gf́gń}, де gf́1Ս… Ս
де К – коефіцієнт, що характеризує кількість розбиття множинних груп
атрибутів, К ∈ [1, gn].
Графічний приклад розбиття досліджуваної таблиці на дочірні
представлений на рисунку 2.9.
63
Рисунок 2.9 – Графічний приклад розбиття досліджуваної таблиці на
дочірні
5. Варіюючи параметр, що характеризує кількість розбиття множинності
груп атрибутів, методика дозволяє отримувати рішення, ефективність яких
оцінюється за допомогою виведеної в межах дослідження цільової функції,
що представлена на рисунку 2.1 [47].
Алгоритм застосування методики складається з наступних етапів:
 на першому етапі визначаються множини, які необхідні для подальшої
оптимізації сховища даних;
 на другому етапі визначаються необхідні параметри оптимізації;
 на третьому етапі формалізується цільова функція мінімізації;
 на четвертому етапі виявляються всі обмеження для цільової функції;
 на п’ятому етапі обчислюється для кожного атрибута величина, що
дорівнює кількості його появ у групі запитів;
 на шостому етапі реалізується сортування атрибутів за частотою їх
появи, виявлення областей атрибутів з однаковою частотою появи;
64
 на сьомому етапі реалізується об’єднання груп атрибутів у дочірні
табличні структури, вибір коефіцієнта розбиття;
 на восьмому етапі отримуємо субоптимальну табличну структуру, що
підвищує продуктивність сховища даних.
Обчислення за методикою для таблиці складається з 9 атрибутів.
Кількість рядків у таблиці RC=600.
6. Параметр TS=9, характеризує кількість стовпців таблиці. Опис полів
подано у таблиці 2.6.
Таблиця 2.6 − Опис полів таблиці
Номер по порядку Найменування стовпця Тип зберігання даних
1. А1 bigint
2. А2 nchar(10)
3. А3 nchar(10)
4. А4 nchar(10)
5. А5 nchar(10)
6. А6 nchar(10)
7. А7 nchar(10)
8. А8 nchar(10)
9. А9 nchar(10)
7. Множинність типів даних атрибутів DBT, які підтримуються обраним
сховищем даних MS SQL 2019. Задано вектором, що характеризує дисковий
простір, що займається типом даних, в байтах DBT={4, 8, 20} [48]. Кількість
типів даних сховища зменшено для компактності викладу. Багато типів
даних сховища MS SQL 2019 може бути представлене у вигляді таблиці 2.7.
Таблиця 2.7 – Множинність типів даних сховища MS SQL 2019
Номер по порядку Найменування типу даних Місце, що займає на
65
дисковому просторі в
байтах
1. int 4
2. bigint 8
3. nchar(10) 20
8. Набір атрибутів (стовпців таблиці) представлено вигляді таблиці 2.8.
Таблиця 2.8 − Набір атрибутів (стовпців таблиці) ТА
DBT1 DBT2 DBT3
А1 0 1 0
А2 0 0 1
А3 0 0 1
А4 0 0 1
А5 0 0 1
А6 0 0 1
А7 0 0 1
А8 0 0 1
А9 0 0 1
9. Множинність, що представляє групу запитів отримання інформації зі
сховища даних, що складається з 4 елементів. Характеристики запитів подано
у вигляді таблиці 2.9.
66
Таблиця 2.9 − Характеристики запитів
Кількість запитів, що Бінарні вектор
Номер по порядку надійшли на сервер за атрибути, що беруть
вибраний період часу участь у запиті
1. 23 <1,0,0,0,1,1,1,1,0>
2. 4 <1,0,0,0,1,0,0,1,1>
3. 15 <0,1,0,1,1,1,0,0,0>
4. 7 <1,1,1,1,1,1,1,1,1>
Відповідно до методики, наступним етапом є обчислення кількості
зустрічей атрибутів у запитах, яка представлена у вигляді таблиці 2.10.
Графічний приклад представлений на рисунку 2.5.
Таблиця 2.10 − Кількість зустрічей атрибутів у запитах
Кількість появ у запитах
А1 34
А2 26
А3 7
А4 22
А5 49
А6 45
А7 30
А8 34
А9 11
Далі набір атрибутів відсортовано. Графічний приклад сортування і
групування атрибутів представлений на рисунку 2.6. Після сортування і
групування отримано розбиття для коефіцієнта. Результат кластеризації та
оцінки розбиття представлені у вигляді таблиці 2.11.
67
Таблиця 2.11 − Результат обчислення альфа рівнів та кластеризації
Значення цільової
Значення функції (Кількість
Елементи альфа-рівня
альфа-рівня блоків, які було
зчитано зі сховища)
{A1, A5, A6, A7, A8, A3, A4, A9, A2} 8 646800
{A2, A3, A4, A9}, {A1, A7, A8, A5, A6} 4 524400
{A3, A9}, {A2, A4, A7} {A1, A8, A6, A5} 2,6 568800
{A3, A9}, {A2, A4}, {A1, A7, A8}, {A5, A6} 2 452400
{A3}, {A4, A9}, {A2}, {A1, A7, A8}, {A5, 1,6 482100
A6}
{A3}, {A9}, {A2, A4}, {A7}, {A1, A8}, 1,3 483600
{A5}, {A6}
{A3}, {A9}, {A4}, {A2}, {A7}, {A1, A8}, 1,14 490800
{A5}, {A6}
Для підвищення продуктивності сховища даних необхідно розділити
табличну структуру на 4 дочірні, представлені у вигляді таблиці 2.12.
Таблиця 2.12 – Отримані табличні структури
Таблиця Атрибути
1. {A3, A9}
2. {A2, A4}
3. {A1, A7, A8}
4. {A5, A6}
Алгоритм застосування методики представлений на рисунку 2.10.
68
Рисунок 2.10 – Алгоритм застосування методики
69
2.4 Висновки до розділу 2
1. Описано предметну область сховищ даних. Надано основні
визначення об’єктів сховищ даних, їх структури, взаємозв’язку, вплив на
продуктивність.
2. Виявлено вплив розміру блоку даних фізичної моделі сховища на
продуктивність.
3. Проведена формалізація задачі оптимізації структури сховища даних,
що включає опис простору рішень, змінних, основних параметрів, цільову
функцію, обмежень.
4. Визначено нелінійний вид цільової функції, виявлено неможливість
розв’язання задачі перебірними методами за прийнятний час через її
розмірність. Запропоновано спосіб зниження розмірності завдання.
5. Запропоновано евристичний алгоритм пошуку субоптимального
поділу таблиці, що ґрунтується на кластерному аналізі групи запитів для
сховищ даних великих інформаційних систем.
6. Розроблено методику субоптимальної реструктуризації табличних
структур сховищ даних невеликих інформаційних систем на основі
багатомодального розподілу атрибутів.
70
РОЗДІЛ 3
МОДЕЛЬ ІНФОРМАЦІЙНОЇ СИСТЕМИ ДЛЯ ПІДВИЩЕННЯ
ПРОДУКТИВНОСТІ ФУНКЦІОНУВАННЯ СХОВИЩ
СТРУКТУРОВАНИХ ДАНИХ
НА БАЗІ МЕТОДИК КЛАСТЕРИЗАЦІІЇ АТРИБУТІВ
3.1 Структурні особливості інформаційних систем
Розроблена інформаційна система підвищення продуктивності сховищ
даних дозволяє отримати рішення як для невеликих інформаційних систем,
заснованих на сховищах даних, так і для великих проєктів. Інформаційна
система реалізована у вигляді вебсервісу, підтримує декілька популярних
сховищ даних, генерує запити на мові SQL, необхідні для реструктуризації
структури сховища даних, а також підтримує можливість оперативного
тестування отриманої структури даних [11, с. 375].
Програмне забезпечення виконує такі функції:
 реалізація довідника сховищ даних;
 реалізація довідника типів даних конкретного сховища даних із
зазначенням величини дискового простору, що займає екземпляр типу;
 реалізація довідника проєктів оптимізації;
 реалізація системи управління запитами у межах проєкту оптимізації;
 реалізація функціоналу управління структурою досліджуваної таблиці
у межах проєкту оптимізації;
 отримання оптимального розбиття досліджуваної таблиці на основі
методики кластерного аналізу групи запитів;
 отримання оптимального розбиття досліджуваної таблиці на основі
методики багатомодального розподілу атрибутів групи запитів;
71
 формування запитів на мові SQL, виконання яких призведе до
реструктуризації сховища даних до структури, запропонованої
системою;
 можливість оперативного тестування одержаної структури сховища
даних для оцінки ефективності застосування методики.
Програмне застосування розроблено в середовищі MS Visual Studio
2022 з використанням технології ASP.NET MVC 5, мовою С#.
Розробка програмного забезпечення ASP.NET MVC 5 є актуальною
версією ASP.NET MVC. Основною перевагою є поділ логіки програмного
забезпечення на три рівні:
Model (модель) – є описом структури даних, за допомогою якої
відбувається інформаційний обмін між ймовірним результатом і
контролером.
View (подання) – це структура відображення даних (моделі) на
сторінках користувача.
Controller (контролер) – містить обробники запитів, що надходять до
вебдодатку [11, с. 376].
Так як технологія ASP.NET MVC заснована на Framework, то до
переваг можна віднести зворотну сумісність програмного забезпечення і
серверної операційної системи Windows, де вона працює.
Функціональне моделювання з використанням нотації IDEF0 у
середовищі Erwin Data Modeler може бути представлене у вигляді діаграми
на рисунку 3.1.
72
Рисунок 3.1 – Функціональна модель даних
Контекстна діаграма, що відбиває найбільш загальний опис
досліджуваного процесу – підвищення продуктивності сховищ даних на
основі методик кластеризації атрибутів. За нею можна зробити висновок про
те, що робота цих об’єктів здійснюється з використанням інформаційної
системи, якій в свою чергу подають дані про характеристики сховища даних,
проєкт оптимізації, що регламентує вплив у вигляді застосування методик
кластерного аналізу і багатомодального розподілу, що управляють впливом у
вигляді дій користувача і результатом роботи є дані про запропоновану
структуру сховища даних і результати тестування нової структури [10, с. 42].
Інформаційна модель системи підвищення продуктивності сховищ
даних представлена на рисунку 3.2.
73
Рисунок 3.2 – Інформаційна модель
74
Інформаційна модель системи містить інформацію про способи
модифікації інформації. Довідники сховищ даних, типів даних, проєктів
оптимізації, запитів на аналіз обробляються користувачем. Запропоноване
рішення виробляється на основі даних, отриманих з довідників і відповідає
обраному способу реструктуризації.
На основі довідників і таблиць генеруються вихідні документи:
 характеристики сховища даних;
 проєкти оптимізації;
 запити для аналізу;
 отримане рішення;
 код для тестування.
Функції системи поділені на службові та основні.
До службових відносять функції відображення модальних вікон, списків,
що випадають, а також валідації даних і користувачів, що авторизувалися.
До основних відносять: введення даних про проєкти оптимізації,
структуру таблиць в межах проєкту оптимізації, набору запитів для аналізу,
ведення довідника типів сховищ даних, типів даних сховищ, виведення
відомостей про запропоноване рішення і згенерований код для тестування
рішення.
Дерево функцій системи представлено на рисунку 3.3.
75
Рисунок 3.3 – Дерево функцій системи
Схема, що описує дерево діалогу, представлена на рисунку 3.4.
76
Рисунок 3.4 – Сценарій діалогу користувача системи
Сценарій діалогу вказує на те, що користувачеві доступне меню
навігації. Пункти меню відповідають функціям інформаційної системи. Далі
за сценарієм пропонується виконати типові операції маніпулювання даними:
 додавання;
 видалення;
 зміна.
3.2 Складові особливості модуля зберігання даних в інформаційній
системі
Сховище даних складається із 9 таблиць розроблених за допомогою
засобів MS SQL 2019 року.
Таблиця Authorise є таблицею, що зберігає інформацію про
користувачів інформаційної системи. Опис полів таблиці може бути поданий
у вигляді таблиці 3.1.
77
Таблиця 3.1 – Структура таблиці Authorise
Поле Тип PK / NULL /
Коментар
FK NOT NULL
Id bigint PK NOT NULL Унікальний номер запису
Login varchar(50) NOT NULL Логін користувача
Password varchar(50) NOT NULL Пароль
Дата створення
CreateDate datetime2(7) NOT NULL
облікового запису
IsActive bit NOT NULL Відмітка про активність
Таблиця AttributeForQuery містить інформацію про атрибути запитів.
Опис полів таблиці може бути поданий у вигляді таблиці 3.2.
Таблиця 3.2 – Структура таблиці AttributeForQuery
NULL /
Поле Тип PK / Коментар
FK NOT NULL
Id bigint PK NOT NULL Унікальний номер запису
QueryId bigint FK NOT NULL Номер запису запитів
AttributeForTa Номер запису атрибута
bigint FK NOT NULL
bleId досліджуваної таблиці
IsInQuery bit NOT NULL Відмітка участі в запиті
Таблиця DataBaseTypes є довідником сховищ даних, що підтримуються
системою. Опис полів таблиці може бути поданий у вигляді таблиці 3.3.
Таблиця 3.3 – Структура таблиці DataBaseTypes
PK NULL /
Поле Тип / Коментар
FK NOT NULL
Id bigint PK NOT NULL Унікальний номер запису
Name varchar(MAX NOT NULL Номер сховища даних
78
Таблиця DataTypes представляє собою таблицю, що зберігає
інформацію про типи даних, що підтримуються сховищем. Опис полів
таблиці може бути поданий у вигляді таблиці 3.4.
Таблиця 3.4 – Структура таблиці DataTypes
NULL /
Поле Тип PK / Коментар
FK NOT NULL
Id bigint PK NOT NULL Унікальний номер запису
varchar(M NOT NULL Назва типу даних
Name
AX)
NOT NULL Розмір типу даних в
SizeInBytes bigint
байтах
DataBaseTypeI NOT NULL Номер запису сховища
bigint FK
d даних
NOT NULL Відмітка, що показує чи є
IsMustSpecifyL
bit тип даних зі змінною
ength
довжиною
Таблиця Projects зберігає інформацію про проєкти оптимізації. Опис
полів таблиці може бути поданий у вигляді таблиці 3.5.
79
Таблиця 3.5 – Структура таблиці Projects
PK NULL /
Поле Тип / Коментар
FK NOT NULL
Унікальний номер
Id bigint PK NOT NULL
запису
Назва проєкту
Name varchar(MAX) NOT NULL
оптимізації
Опис проєкту
Description varchar(MAX) NOT NULL
оптимізації
Номер запису сховища
DataBaseTypeId bigint FK NOT NULL
даних
CreateDate datetime2(7) NOT NULL Дата створення проєкту
Номер облікового запису
OwnerId bigint FK NOT NULL
власника
Таблиця Queries зберігає інформацію про проаналізовану групу запитів.
Опис полів таблиці може бути поданий у вигляді таблиці 3.6.
Таблиця 3.6 – Структура таблиці Queries
PK / NULL /
Поле Тип Коментар
FK NOT NULL
Унікальний номер
Id bigint PK NOT NULL
запису
Опис проєкту
Description varchar(MAX) NOT NULL
оптимізації
ProjectId bigint Номер запису проєкту
FK NOT NULL
оптимізації
Frequency bigint Кількість появ запиту за
NOT NULL
звітний період
80
Таблиця TableForProject зберігає відомості про досліджувану таблицю
у межах проєкту оптимізації. Опис полів таблиці може бути поданий у
вигляді таблиці 3.7.
Таблиця 3.7 – Структура таблиці TableForProject
NULL /
Поле Тип PK / Коментар
FK NOT NULL
Унікальний номер
Id bigint PK NOT NULL
запису
Назва атрибута
AttributName varchar(MAX) NOT NULL
таблиці
Номер запису проєкту
ProjectId bigint FK NOT NULL
оптимізації
Номер запису типу
AttributTypeId bigint FK NOT NULL
даних
Lenght bigint NOT NULL Довжина атрибуту
Таблиця TableForConstraint зберігає інформацію про обмеження. Опис
полів таблиці може бути поданий у вигляді таблиці 3.8.
Таблиця 3.8 – Структура таблиці TableForConstraint
NULL /
Поле Тип PK / Коментар
FK NOT NULL
Унікальний номер
Id bigint PK NOT NULL
запису
Назва обмеження
ConstraintName varchar(MAX) NOT NULL
таблиці
Номер запису проєкту
ProjectId bigint FK NOT NULL
оптимізації
81
Таблиця AttributeForConstraint зберігає інформацію про атрибути,
включені до обмеження. Опис полів таблиці може бути поданий у вигляді
таблиці 3.9.
Таблиця 3.9 – Структура таблиці AttributeForConstraint
NULL /
Поле Тип PK / Коментар
FK NOT NULL
Унікальний номер
Id bigint PK NOT NULL
запису
Номер запису
ConstraintId varchar(MAX) NOT NULL
обмеження
AttributeForT Номер запису атрибуту
bigint FK NOT NULL
ableId досліджуваної таблиці
Залежності та відносини між таблицями зображені на діаграмі рисунку
3.5.
Рисунок 3.5 – Діаграма відношень в реляційному сховищі даних
82
Додаток складається з 8 сторінок і вікон. Дерево сторінок програми
представлено на рисунку 3.6.
Рисунок 3.6 – Дерево сторінок програми
Об’єктна модель даних додатка представлена рисунку 3.7.
83
Рисунок 3.7 – Об’єктна модель даних додатка
3.3 Схематизація програмного забезпечення інформаційної системи
Так як спроєктоване програмне забезпечення є вебсервісом, то список
програмних модулів може бути представлений у таблиці 3.10.
84
Таблиця 3.10 – Список програмних модулів
№ Найменування
п/п модуля Функції модуля
1. Модуль авторизації Модуль авторизації містить провайдер ролей і
провайдер членства. Забезпечує захист системи
від несанкціонованого доступу.
2. Модуль службових До службових довідників належать довідники
довідників видів сховищ даних, типів даних. Модуль
відображає інформацію про них.
3. Модуль проєктів Забезпечує відображення, додавання,
оптимізації редагування і видалення проєктів оптимізації.
Також забезпечує врахування структури таблиці
оптимізації, набору запитів для аналізу.
4. Модуль методики Модуль обчислює запропоноване системою
заснованої на рішення, і навіть генерує програмний код для
кластерному аналізі реструктуризації сховища даних, проведення
групи запитів тестів.
5. Модуль методики Модуль обчислює запропоноване системою
заснованої на рішення, і навіть генерує програмний код для
багатомодальному реструктуризації сховища даних, проведення
розподілі атрибутів тестів.
запитів
6. Модуль повного Модуль обчислює точне рішення шляхом
перебору перебору. Має обмеження щодо розмірності
вхідних даних.
7. Модуль валідації Модуль в інтерактивному режимі обробляє
даних потік вхідних даних користувача відповідно до
правил допустимості інформації. У разі невдачі
видає повідомлення про необхідність перевірки
правильності введення.
8. Модуль бази даних Модуль сховища даних містить типові запити
щодо взаємодії зі сховищем у межах об’єктної
моделі.
85
Модуль повного перебору дозволяє на невеликих розмірностях
одержати оптимальне рішення задачі поділу табличних структур. Алгоритм
роботи модуля полягає у послідовному переборі множинності рішень,
перевірці задоволення обмеженням, обчисленні цільової функції,
представлений на рисунку 3.8.
Рисунок 3.8 – Алгоритм роботи модуля повного перебору
86
Модулі, що реалізують розроблені методики вертикального поділу
табличних структур даних, одержують дані проєкту оптимізації із сховища
даних. Вихідними даними модулів є пропонований поділ табличної
структури, запити її зміни, оцінки ефективності отриманих табличних
структур, і навіть всі етапи обчислення рішення.
Однією з функцій модулів є створення запитів на генерацію нових
табличних структур відповідно до отриманого рішення. Алгоритм створення
запитів на генерацію нових табличних структур представлено на рисунку 3.9.
Рисунок 3.9 – Алгоритм створення запитів на створення нових
табличних структур
87
Для оцінки ефективності отриманих табличних структур інформаційна
система перетворює програмний код запитів на читання даних під нові
структури даних. Оцінка ефективності полягає у виконанні запитів, що
вимагають виконання операцій повного сканування табличних структур, що
беруть участь у запиті. Це досягається за допомогою логічного оператора
«OR» в частині запиту, в якій описуються умови виконання запиту. Алгоритм
перетворення запитів на читання даних до нових табличних структур
представлений малюнку 3.10.
Рисунок 3.10 – Алгоритм перетворення запитів на читання даних
до нових табличних структур
88
Усі інформаційні потоки при формуванні документів ІС проходять
через модуль валідації даних, потім обробляються і перетворюються на
запити SQL у модулі сховища даних. Дерево виклику програмних модулів
представлене рисунку 3.11.
Рисунок 3.11 – Дерево виклику програмних модулів
Інтерфейс ІС представлений на рисунку 3.12.
Рисунок 3.12 – Інтерфейс ІС
Сторінка з результатом роботи методики і згенерованими скриптами
представлена на рисунку 3.13.
89
Рисунок 3.13 – Сторінка з результатом роботи методики і
згенерованими скриптами
3.4 Висновки до розділу 3
1. Розроблено інформаційну систему підвищення продуктивності
сховищ даних на основі методик кластеризації атрибутів, із застосуванням
технологій вебдодатків на платформі ASP.NET MVC 5, СУБД Microsoft Sql
Server 2019.
2. В інформаційній системі реалізовано функції управління проєктами
оптимізації, структурою таблиць оптимізації, набором запитів для аналізу.
3. Інформаційна система пропонує рішення щодо реструктуризації
даних, а також генерує для цих цілей програмний код і проводить тестування
отриманих результатів.
90
ВИСНОВКИ
У кваліфікаційні роботі магістра «Моделювання інформаційної системи
для підвищення продуктивності функціонування сховищ структурованих
даних», проведено аналіз методів і засобів підвищення продуктивності
інформаційних систем; формалізовано задачу оптимізації моделі даних
інформаційних сховищ у вигляді теоретико-множинної моделі; розроблено
евристичний алгоритм пошуку субоптимального поділу таблиці, що
базується на кластерному аналізі групи запитів для сховищ даних великих
інформаційних систем; розроблено методики субоптимальної
реструктуризації табличних структур сховищ даних невеликих
інформаційних систем на основі багатомодального розподілу атрибутів;
розроблено систему підвищення продуктивності сховищ даних з
урахуванням методик кластеризації атрибутів.
Під час роботи над кваліфікаційною роботою магістра було
опрацьовано 24 літературних джерела, що дало можливість у повному обсязі
розкрити тему кваліфікаційної роботи магістра.
Моделювання сховища даних – це створення візуального уявлення про
всю інформаційну систему або її частину. Мета полягає в тому, щоб
проілюструвати типи даних, які використовуються і зберігаються в системі,
відносини між цими типами даних, способами групування та організації
даних, їх форматами та атрибутами. Моделі даних будуються з урахуванням
бізнес-потреб. Правила і вимоги до моделі даних визначаються заздалегідь на
основі зворотного зв’язку із замовником, тому їх можна включити у розробку
нової системи або адаптувати до наявної.
Дані можна моделювати на різних рівнях абстракції. Процес
починається зі збору вимог від зацікавлених сторін і кінцевих користувачів.
Ці правила потім перетворюються на структури даних. Модель сховища
даних можна порівняти з дорожньою картою, планом архітектора або будь-
91
якою формальною схемою, що сприяє глибшому розумінню того, що
розробляється.
Підхід до моделювання інформаційної системи організаційного
управління полягає у поданні системи як людино-машинної системи.
Основними засобами моделювання сховища даних є: бібліотека моделей,
каталог методів і програмно-технічних засобів для їх реалізації.
У роботі було проаналізовано.
1. Проаналізовано типові структури інформаційних систем, їх переваги,
недоліки, поширення. Виявлено, що основними архітектурами
інформаційних систем є трирівнева архітектура з «тонким клієнтом» –
браузером, вебсервером і сховищем даних.
2. Систематизовано методи підвищення продуктивності інформаційних
систем на основі сховищ даних. Виявлено негативний вплив віку
інформаційної системи на продуктивність.
3. Проведено аналіз методів підвищення продуктивності сховищ даних,
за результатами якого було виявлено їх переваги і недоліки. Обґрунтовано
вибір методу зберігання даних на основі вертикально розподілу таблиць.
4. Описано предметну область сховищ даних. Надано основні
визначення об’єктів сховищ даних, їх структури, взаємозв’язку, вплив на
продуктивність.
5. Виявлено вплив розміру блоку даних фізичної моделі сховища на
продуктивність.
6. Проведено формалізацію задачі оптимізації структури сховища
даних, що включає опис простору рішень, змінних, основних параметрів,
цільову функцію, обмежень.
7. Визначено нелінійний вид цільової функції, виявлено неможливість
розв’язання задачі перебірними методами за прийнятний час через її
розмірність. Запропоновано спосіб зниження розмірності завдання.
92
8. Запропоновано евристичний алгоритм пошуку субоптимального
поділу таблиці, що базується на кластерному аналізі групи запитів для
сховищ даних великих інформаційних систем.
9. Розроблено методику субоптимальної реструктуризації табличних
структур сховищ даних невеликих інформаційних систем на основі
багатомодального розподілу атрибутів.
10. Розроблено інформаційну систему підвищення продуктивності
сховищ даних на основі методик кластеризації атрибутів, із застосуванням
технологій вебдодатків на платформі ASP.NET MVC 5, СУБД Microsoft Sql
Server 2019.
11. В інформаційній системі реалізовано функції управління проєктами
оптимізації, структурою таблиць оптимізації, набором запитів для аналізу.
12. Інформаційна система пропонує рішення щодо реструктуризації
даних, а також генерує для цього програмний код і проводить тестування
отриманих результатів.
93
СПИСОК ВИКОРИСТАНИХ ДЖЕРЕЛ
1. Авраменко В. С., Авраменко А. С. Проектування інформаційних систем:
навч. посібник. Черкаси: Черкаський національний університет
ім. Б. Хмельницького, 2017. 434 с.
2. Azadeh A., Sharifi S., Saberi M. Design and Implementation of a Human
Centered Expert System for Improvement of Strategic Planning in a
Manufacturer of Construction Products. Australian Journal of Basic and
Applied Sciences. 2009. Vol. 3. Is. 3. P. 2447-2458.
3. Беркман Л., Бараш О., Мусієнко А., Ткаченко О., Лаптєв О., Свинчук О.
Інтелектуальна система управління для інфокомунікаційних мереж.
Системи управління, навігації та зв’язку. Збірник наукових праць. 2022.
Т. 3 (69). С. 54-59. –
4. Борукаєв З. Х. Математичні та комп’ютерні моделі процесів
вдосконалення механізмів функціонування і розвитку систем
організаційного правління: дис. .... д. т. наук: 01.05.02 / Інститут проблем
моделювання в енергетиці ім. Г. Є. Пухова. Київ, 2018. 342 с.
5. Boroński, R., Bocewicz, G. Relational Database Index Selection Algorithm.
Communications in Computer and Information Science. 2014. Vol. 3. P. 338-
347.
6. Gelinas U., Sutton S., Fedorowicz J. Business processes and information
technology. Cincinnati: South-Western / Thomson Learning, 2004. 952 p.
7. Додонов О.Г. Комп`ютерне моделювання процесів організаційного
управління. Вісник НАН України. 2016. № 1. С. 69 – 71.
8. Донець В., Кучук Н., Шматков С. Моделювання інформаційної системи
e-learning з використанням генетичних алгоритмів. Системи управління,
навігації та зв’язку. Збірник наукових праць. 2018. Т. 3 (49). С. 153-156.
94
9. Жигайло О. М. Використання технології Data Mining в автоматизованій
системі простежуваності виробництва сирої соняшникової олії.
Автоматизація технологічних і бізнес-процесів. 2014. № 9. С. 30-38.
10. Жигайло О. М. Борис В. В. Кластерний аналіз в автоматизованих
системах простежуваності. Автоматизація технологічних і бізнес-
процесів. 2018. Volume 10, Issue 1. С. 39-46
11. Cuzzocrea A. Data Warehousing and OLAP over Big Data: a survey of the
stateoftheart, open problems and future challenges. International Journal of
Business Process Integration and Management. 2015. № 17 (4): Р. 372-377.
12. Kuchuk G. A., Kovalenko А. А., Mozhaev A. A. An Approach To
Development Of Complex Metric For Multiservice Network Security
Assessment. Statistical Methods Of Signal and Data Processing (SMSDP –
2010): Proc. Int. Conf., October 13-14, 2010. Kiev: NAU, RED, IEEE
Ukraine section joint SP, 2010. P. 158 – 160.
13. Лисак В. Формування систем підтримки прийняття управлінських
рішень на основі ІТ-засобів. European Journal of Economics and
Management. 2020. Vol. 5. Is. 1. P. 41-50.
14. Марченко А. Проектування інформаційних систем. К. 2016. 90 с.
15. Методологія інформаційних систем та баз даних: теоретичний і
практичний підходи : навч. посібник / уклад. Ю. О. Ушенко,
М. Л. Ковальчук, М. С. Гавриляк, А. Л. Негрич. Чернівці: Чернівецький
нац. ун-т ім. Ю. Федьковича, 2021. 240 с.
16. Недашківський О. М. Планування та проектування інформаційних
систем. Київ, 2014. 215 с.
17. Пасічник В. В., Литвин В. В., Шаховська Н. Б. Проектування
інформаційних систем: навч. Посібник. Львів: 2013. 380 с.
18. Проєктування інформаційних систем: Загальни питання теорії
проектування ІС. / уклад. О. С. коваленко, Л. М. Дубровська. К.: КПІ ім.
Ігоря Сікорського, 2020. 192 с.
95
19. Ременяк Л. В. Проектування інформаційних систем: конспект лекцій.
Одеса: Одеський державний екологічний університет, 2016. 152 с.
20. Ситник В. Ф., Писаревська Т. А., Єрьоміна Н. В., Краєва О. С. Основи
інформаційних систем: навч.посібник. К.: КНЕУ, 2001. 420 с.
21. Sauter V. Decision support systems for business intelligence (2nd ed.).
Hoboken, N. J: Wiley & Sons, 2010. 480 p.
22. Fitzgerald S. Decision making. Oxford: Capstone Publishing, 2002. 146 p.
23. Шматков С. І., Кучук Н. Г., Донець В. В. Модель інформаційної
структури гіперконвергентної системи підтримки електронних
обчислюваль- них ресурсів університетської е-learning. Системи
управління, навігації та зв’язку : науковий журнал. 2018. Вип. 2(48). С.
97-100.
24. Yu N., Johnson R., Sherick R., Hong M., Loparo K. Big Data Analytics in
Power Distribution Systems. Innovative Smart Grid Technologies Conference
(ISGT). 2015. P. 1-5.