Translate this page:
Please select your language to translate the article


You can just close the window to don't translate
Library
Your profile

Back to contents

Cybernetics and programming
Reference:

Developing the Best Possible Data Storage Structure for Decision Support Systems

Suchkova Elena Alexandrovna

post-graduate student of the Department of Information Protection in Computing Systems at Izhevsk State Technical University

426069, Russia, Republic of Udmurtia, Izhevsk, str. Studencheskaya, 7

hellenaalex@gmail.com
Nikolaeva Yuliya Viktorovna

post-graduate student of the Department of Information Protection in Computing Systems at Izhevsk State University

426069, Russia, Republic of Udmurtia, Izhevsk, str. Studencheskaya, 7

smail-nuv@mail.ru

DOI:

10.7256/2306-4196.2016.4.18281

Received:

10-03-2016


Published:

26-08-2016


Abstract: The article presents the results of the development and experimental comparison of data structures and data storage methods. The basis for building the models included the financial market decision support system and expert evaluations of the electronic tendering system. In both cases the authors built conceptual data models, stored data in text files, relational and non-relational databases and evaluated efficiency of an organized structure from the point of view of efficient storage and access, automatic integrity control and data consistency. By using theoretical methods (abstraction, analysis, synthesis, and idealization) the authors developed conceptual database models. In its turn, by using empirical methods (experiment and comparison) they checked the efficiency of data storage with the use of text files, relational and non-relational databases. As the main conclusion of the research, the authors provide recommendations on how to select the best data storage structures for electronic decision support systems. The experimental comparison allowed to discover that for a developed expert evaluation storage structure the relational database control system is the most effective method while in case of storing information about financial markets, it is better to use text files for a developed decision support system. 


Keywords:

data, database, relational database, non-relational database, desicion support, development, information system, structure, expert evaluation, financial market


Одним из ключевых аспектов в разработке информационной системы является решение вопроса о выборе оптимальной структуры данных и способов работы с ними. Структура данных – это совокупность типизированных единиц информации и логических связей между ними, позволяющая хранить и обрабатывать данные, обеспечивая их целостность, непротиворечивость, связность и эффективность доступа к каждому модулю или блоку информации с целью его обработки или визуализации. Современные алгоритмы и программные средства обработки данных предоставляют возможности хранения и визуализации данных в разнообразных форматах. Выбор структуры хранения данных на ранних этапах работы с информационными массивами может помочь ускорить ввод данных, сделать более ясным представление данных и повысить эффективность работы аналитических алгоритмов. Работа с данными включает в себя этапы сбора данных, ввода и хранения, обработки и предоставления результатов. Эффективная структура хранения данных позволяет снизить временные затраты на ввод данных и ускорить обработку данных и получение отчетов.

Исходные данные могут быть получены из разных источников и быть представлены в разнообразных форматах: в виде текстовых файлов, документов, таблиц, веб-страниц, выгрузок в форматах xml, csv, и других. Данные могут содержать пробелы или дубликаты, ошибочные значения, противоречия. Перед обработкой данных, представленных в таких форматах необходимо их преобразовать к виду, удобному для применения аналитических алгоритмов, то есть применить процедуры и методы, позволяющие извлечь данные из разнообразных источников, преобразовать их в единый формат, нормировать данные, избавиться от пробелов, дубликатов, ошибок данных. Подробнее о нормировке данных описано в статьях [1][2]. Этот этап называется консолидацией данных и результатом этого этапа являются данные, представленные в оптимальном для обработки виде. Критерии, на основе которых делается вывод о целесообразности использования той или иной структуры для представления данных в порядке понижения их приоритетов: эффективный доступ к данным, автоматизация обеспечения целостности и непротиворечивости данных, скорость получения данных, минимизация объема хранения данных.

Наиболее удобными для работы с экономическими данными структурами являются массивы, графы[3], деревья, то есть данные могут быть представлены с помощью реляционных, иерархических или объектно-ориентированных моделей данных. Каждая из моделей в свою очередь может храниться в бинарных файлах, базах данных или текстовых файлов сложных форматов, таких как xml, csv. Каждый способ хранения имеет свои достоинства и недостатки, рассмотрим их с точки зрения трех критериев: транзакционность, аудит и многопоточность. Текстовые файлы могут быть открыты без использования специальных средств, но не позволяют на уровне хранилища данных обеспечивать целостность и достоверность информации, они также не поддерживают транзакционность, аудит, многопоточность. Бинарные файлы позволяют хранить данные в любом удобном формате, но доступ к этим данным невозможен без разработанных для этого инструментов, транзакционность и аудит также должны быть реализованы на уровне приложения. Базы данных поддерживают аудит, транзакционность, многопоточность, что позволяет сохранить целостность и достоверность данных. Ключи и ограничения на значения полей данных позволяют на уровне хранилища данных контролировать их формат, согласованность, отсутствие дубликатов. Если информация имеет структуру, которую сложно или неэффективно представлять в виде связанных отношениями таблиц, то нереляционные базы данных позволяют работать с информацией на уровне объектов, что позволяет оперировать в приложении бизнес-сущностями без создания сложных запросов, но в то же время снижает гарантии на автоматическую проверку согласованности и целостности данных. Теоретически верно выбранные структура данных и способ хранения могут оказаться несостоятельными на практике, в силу сложности предсказания наиболее используемых запросов и вероятности возникновения узких мест в системах. Эта неопределенность обусловлена разнообразием аналитических алгоритмов, которые могут потребовать определенные алгоритмы работы с имеющимися данными. Рассмотрим примеры сравнения моделей и средств хранения данных на двух примерах. Первый пример содержит упрощенную информационную модель экспертных оценок системы поддержки принятия решения по выбору поставщика [4]. Второй пример содержит модель данных для принятия решения на фондовом рынке [5]. Для каждого примера разработаем концептуальную схему данных и реализуем её хранение в реляционной и нереляционной базах данных, а также, если это возможно, в текстовом файле. Выбор системы управления базы данных является комплексным аналитическим процессом, особенности которого описаны подробнее в [6][7][8]. В качестве реляционной базы данных выбран сервер MySQL 5.6. В качестве нереляционной базы данных выбран MongoDB 3.0.

Рассмотрим логическую схему блока данных электронной системы проведения тендеров, относящуюся к критериям отбора и экспертным оценкам. Основные сущности: Пользователи (Users), Анкеты (Questionary), Вопросы (Question), Ответы (Answer), Типы ответов (AnswerType), Ответ на вопрос (QuestionResult). Каждый вопрос имеет идентификатор, текст и тип ответа (внешний ключ на таблицу AnswerType): свободный ответ, выбор одного из вариантов, множественный выбор и так далее. У каждой анкеты есть идентификатор, текст (название и описание), автор (внешний ключ на таблицу Users). Для тестов с вариантами ответа заполняются значения в таблицу Answer: идентификатор, текст ответа, идентификатор вопроса (внешний ключ на таблицу Question). Схема данных представлена на рисунке 1.

pic1

Рисунок 1 Схема базы данных сбора экспертных оценок

Для данной схемы реализован программный код на языке Java, созданы базы данных в MySQL и MongoDB. Далее последовательно было проведено сравнение времени выполнения запросов на добавление, обновление и получение данных (запросы выполнялись последовательно в 1 поток). Результаты экспериментальных запусков представлены в таблице 1.

Таблица 1

Анализ эффективности способов хранения информации об экспертных оценках электронной системы проведения тендеров

Способ хранения

Время добавления

10 000 записей, сек.

Время получения

100 000 записей, сек.

Время обновления

10 000 записей, сек.

Реляционная база данных MySQL

7

5

8

Нереляционная база данных MongoDB

8

67

27

По таблице видно, что запросы к реляционной базе данных на получение данных требуют меньше времени на выполнение. То есть по скорости доступа к данным нереляционная база данных уступает реляционной.

Ниже представлена концептуальная схема данных о динамике показателей на фондовой бирже: котировки фьючерса нефти сорта BRENT (таблица ice_brn содержит ежедневные данные о максимальном, минимальном, среднем значении), промышленный индекс Доу – Джонса (таблица dji), индексы AEX, IPC,PTC, Фьючерс на S&P 500 (соответственно таблицы aex,ipc,ptc, sp500vix содержат почасовые изменения). Данные представляют собой временные ряды значений указанных показателей. Статистические и эконометрические зависимости между данными высчитываются и реализуются на уровне аналитического приложения, то есть при формировании структуры хранения данных они считаются независимыми. Изменение во времени и независимость показателей друг от друга диктуют необходимость хранить их в отдельных, не связанных отношениями таблицах, либо осуществлять связь только на основе даты и времени. В качестве первичного ключа, гарантирующего отсутствие дубликатов логично выбрать поле, содержащее timestamp значение точной даты и времени.

pic2

Рисунок 2 Схема базы данных о показателях фондовой биржи

Для данной схемы разработан программный код на языке Java, реализующий хранение данных в csv файлах, базах данных MySQL и MongoDB. Разработаны методы для генерации данных, чтения записей и обновления записей для каждого способа. Результаты измерения скорости работы каждого из них представлены в таблице 2.

Таблица 2

Анализ эффективности способов хранения данных фондовых бирж

Способ хранения

Время добавления

10 000 записей, сек.

Время получения

100 000 записей, сек.

Время обновления

10 000 записей, сек.

Csv файл

4,6

1,576

9

Реляционная база данных MySQL

7

4

8

Нереляционная база данных MongoDB

1,7

39

4

Итак, согласно проведенному эксперименту, оптимальным способом хранения данных с финансовых рынков является csv файл. Можно выделить следующие достоинства:

- высокая скорость доступа к данным;

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

- отсутствие необходимости преобразования данных;

Высокая скорость доступа к файлу в сравнении с базами данных достигается за счет отсутствия затрат на открытие соединения к базе данных, авторизацию, преобразование форматов, контроль целостности и согласованности. Так как из источников данных о биржевых показателях возможна выгрузка сразу в csv формат, то нет необходимости преобразовывать данные, удобнее работать сразу с той структурой, которая предоставляется биржевыми сервисами.

Недостатки хранения данных в csv файлах следующие:

- отсутствие автоматического контроля согласованности и целостности;

- сложность параллельной работы;

- отсутствие транзакционности.

Недостатки использования файлов вместо базы данных для рассматриваемого примера не играют значительной роли. Поскольку для принятия решения на рынке необходима, как правило, самая последняя информация, имеет смысл каждый раз получать новые данные из стороннего сервиса, так что за контроль их целостности и согласованности будет отвечать источник данных. Параллельная работа также не является приоритетным направлением разрабатываемой системы поддержки принятия решения на бирже, так как это приложения является локально установленной программой для каждого пользователя. Необходимости параллельной работы с данными в данном случае нет. Транзакционность не является обязательным требованием, ввиду однопользовательской работы и особенностями процесса поддержки принятия решения, которые не требуют обновления данных, а только лишь чтения и добавления новых.

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

Необходимо отметить, что все выводы об эффективности структур данных и реализаций хранения в базах данных сделаны для описанных примеров, то есть для разработанных схем данных и программных продуктов с их функционалом и требованиями. Данные выводы не могут быть расширены на другие, пусть даже и схожие, структуры данных и алгоритмы без дополнительных проверок. Все эксперименты осуществлялись на 1 компьютере, серверы баз данных, файлы и приложения располагались локально. Развертывание кластеров баз данных, разнесение приложения и серверов баз данных на разные машины, изменение структуры данных или технологий взаимодействия с хранилищами данных, денормализация данных, и другие изменения могут привести к значительному изменению метрик, а, следовательно, и к целесообразности изменения хранилища данных или способа доступа к нему.

References
1. Lyalin V.E., Suchkova E.A. Problemy vybora postavshchika-kriterii, instrumenty i metody otsenki // Matematicheskie modeli i informatsionnye tekhnologii v organizatsii proizvodstva. 2012. № 2 (25). S. 39-48.
2. Nikolaeva Yu.V. Normirovka dannykh dlya neironnykh setei. Molodye uchenye-uskoreniyu nauchno-tekhnicheskogo progressa v XXI veke: sb.tr. nauchn.-tekhn. konf. aspirantov, magistrantov i molodykh uchenykh. 2011. T. 1 . C. 210-216.
3. Malikov A.V. Orientirovannye grafy v relyatsionnykh bazakh dannykh // Upravlenie, vychislitel'naya tekhnika i informatika Doklady TUSURa, № 2 (18), chast' 2, dekabr' 2008. S. 100-104.
4. Suchkova E.A. Using agent-based approach to implementation of supply processes // Modern informatization problems in the technological and telecommunication systems analysis and synthesis: Proceedings of the XX-th International Open Science Conference (Yelm, WA, USA, January 2015)-Yelm, WA, USA: Science Book Publishing House, 2015. P. 399-404. ISBN 978-1-62174-078-0
5. Nikolaeva Yu.V. Raspoznavanie krizisnykh patternov v kotirovkakh f'yuchersov na neft' sorta Brent // Molodye uchenye – uskoreniyu nauchno-tekhnicheskogo progressa v XXI veke: sbornik materialov III Vserossiiskoi nauchno-tekhnicheskoi konferentsii aspirantov, magistrantov i molodykh uchenykh s mezhdunarodnym uchastiem, Izhevsk, 22-23 aprelya 2015 goda / IzhGTU imeni M.T. Kalashnikova. 1010 s.
6. Lisin S.I. Obzor i sravnitel'nyi analiz sistem upravleniya nerelyatsionnymi bazami dannykh // Molodezhnyi nauchno-tekhnicheskii vestnik. 2013. № 5. FGBOU VPO «MGTU im. N.E. Baumana». S. 1-12. URL: http://sntbul.bmstu.ru/file/out/574615
7. Kozlov I.A. Analiz i klassifikatsiya nerelyatsionnykh baz dannykh // Molodezhnyi nauchno-tekhnicheskii vestnik №02, FGBOU VPO «MGTU im. N.E. Baumana». C. 1-23. URL: http://sntbul.bmstu.ru/file/out/552140
8. Luchinin Z.S. Struktura dannykh dlya dokumento-orientirovannykh baz dannykh // Programmnye sistemy i vychislitel'nye metody. 2013. № 3. C. 230 - 232. DOI: 10.7256/2305-6061.2013.3.10772.
9. Bondarenko I.B., Korobeinikov A.G., Prokhozhev N.N., Mikhailichenko O.V. Prinyatie tekhnicheskikh reshenii s pomoshch'yu mnogoagentnykh sistem // Kibernetika i programmirovanie. 2013. № 1. C. 16 - 20. DOI: 10.7256/2306-4196.2013.1.8305. URL: http://www.e-notabene.ru/kp/article_8305.html