Developing the Best Possible Data Storage Structure for Decision Support Systems

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

Исходные данные могут быть получены из разных источников и быть представлены в разнообразных форматах: в виде текстовых файлов, документов, таблиц, веб-страниц, выгрузок в форматах 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.

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

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

Таблица 1

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

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

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

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

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

Таблица 2

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

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

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

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

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

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

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

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

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

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

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

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

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