Труды КНЦ вып.9 (ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ) вып. 9/2019(10)

отнести временные ряды. В этом случае гораздо эффективнее применять реляционную модель, в которой можно хранить элементы данных транзакций некоторого вида в рамках одной таблицы (реляционного отношения). В таком случае выполнение сложных аналитических запросов, благодаря различным механизмам индексации, будет выполняться наиболее эффективно. В этом случае анализ данных более ориентирован (как и сама реляционная модель) на учет связей между элементами данных одного вида (далее будем называть эти связи «вертикальными»). Например, в некоторой таблице «Закупка компонентов» каждый кортеж будет отражать данные одной транзакции - дата, количество, поставщик, цена, название компонента. Соответственно любой аналитический запрос будет подразумевать изначальное получение идентификаторов некоторых кортежей как ссылки на некоторые целостные сложные элементы данных (например, закупочные транзакции), а уже потом обработку значений их полей. Таким образом, реляционная модель подходит в большей степени для анализа элементов данных с неизменной структурой, которые можно представить в рамках одной таблицы. При этом она эффективно формирует «вертикальные» связи в процессе выполнения запроса. Например, сортирует ежемесячные закупке по цене. Связи между элементами данных разных видов (далее будем называть их «горизонтальными») установлены на этапе загрузки данных в таблицу в соответствии типами ее полей. Например, названия поставщиков будут распределены по таблице «Закупка компонентов» с учетом того в какое время, какое количество, какого компонета, по какой цене было у них закуплено. Поэтому применение реляционной модели в отношении анализа транзакционных данных, каждый вид которых имеет неизменную структуру, дающую возможность заранее сформировать «вертикальные» связи, более предпочтителен. Однако, если необходимо анализировать данные, представленные в разных таблицах, то этом случае «вертикальные» связи нужно формировать на этапе выполнения запроса с помощью операции соединения таблиц. Увеличение числа объединяемых таблиц с большим количеством числом кортежей могут сделать время выполнения запроса неприемлемым. Поэтому в случае, если число учитываемых при аналитических операциях связей велико и их перечень в разных запросах трудно предсказать, то в этом случае можно рассматривать возможность применения графовой модели, в которой и «вертикальные» и «горизонтальные» связи задаются явно в виде дуг графа, что сводит операции соединения таблиц к поиску путей между вершинами. К таким данным можно отнести нормативно-справочные данные (Reference Data Management, RDM), и мастер-данные (Master Data Management, MDM). Отдельно отметим, что графовую модель и соответствующую ей СУБД рекомендуется использовать при решении задач анализа данных, в которых объект анализа в реальности представляет собой сетевую структуру. Например, социальная сеть, коммутационная сеть, логистическая сеть и т.д. В этом случае моделирование упрощается ввиду сходства элементом модели данных и частей объекта моделирования и представляется возможность «в лоб» применить графовые алгоритмы. Противоположной ситуацией является та, в которой объект моделирования необходимо сводить к графовой модели (например, набор текстовых документов). В этом случае при таком сведении для успешного проведения аналитических процедур следует изначально ориентироваться на применение и последующую интерпретацию результатов применения выбранных 143