CC BY
93
УДК 351.862.216.36
Федин Ф.О., Чискидов С.В., Безвесилъная А.А.
СОВЕРШЕНСТВОВАНИЕ СИСТЕМЫ ХРАНЕНИЯ И АНАЛИТИЧЕСКОЙ ОБРАБОТКИ ДАННЫХ ОБЪЕКТОВ МЧС РОССИИ КАК ОСНОВА ОБЕСПЕЧЕНИЯ ПОСТОЯННОЙ ГОТОВНОСТИ СИЛ И СРЕДСТВ
ГРАЖДАНСКОЙ ОБОРОНЫ
В работе представлены результаты, исследования вопросов применимости технологий хранилищ данных в деятельности различных объектов МЧС России, включая объекты гражданской обороны. Сформулированы обобщенные требования, к хранилищам, данных объектов МЧС России, выполнен анализ реляционной, многомерной и гибридной моделей их построения.
Ключевые слова: хранилище данных, модель данных, измерения, факты.
Fedin F.O., Chiskidov S.V., Bezvesilnaya А.А.
IMPROVING THE SYSTEM STORAGE AND ANALYTICAL PROCESSING OF THE DATA OF OBJECTS OF THE EMERGENCY OF RUSSIA AS THE BASIS OF PROVIDING PERMANENT PREPAREDNESS FORCE AND MEANS OF CIVIL
DEFENSE
The paper presents the results of a study of the issues of applicability of data warehouse technologies in the activities of various facilities of the Ministry of Emergency Situations of Russia, including civil defense facilities. The generalized requirements for the data warehouses of the EMERCOM facilities are formulated, the relational, multi-dimensional and hybrid models of their construction are analyzed.
Keywords: storage of data, model of data, measurements, facts.
Постоянная готовность сил и средств гражданской обороны (далее - ГО) - это такое их состояние, при котором обеспечивается возможность организованного, в установленные сроки, начала выполнения ими поставленных задач и успешного решения этих задач в любых условиях складывающейся обстановки. Обеспечение постоянной готовности сил и средств ГО к выполнению задач по их предназначению является важной и ответственной задачей руководителей всех уровней управления ГО. При этом в качестве объектов управления силами и средствами ГО выступают спасательные воинские формирования федерального органа исполнительной власти, уполномоченного на решение задач в области гражданской обороны, подразделения федеральной противопожарной службы, аварийно-спасательные формирований и спасательные службы и др. В рамках данной статьи эти объекты будут рассматриваться как часть общей совокупности всех объектов МЧС Гос-сии.
Необходимость исследования подходов к со-
вершенствованию системы хранения и аналитической обработки данных объектов МЧС Гос-сии обусловлена наличием следующего практического противоречия. С одной стороны, возможности применения учетных систем объектов МЧС Госсии для целей аналитической обработки данных и построения на их основе систем поддержки и принятия решений весьма ограничены. Это связано с тем, что учетные системы создавались и предназначены для автоматизации рутинных операций повседневной деятельности - ведение карточек тушения пожаров, начисление заработной платы сотрудников, учет складских запасов имущества и т.д. Основные требования к таким системам - обеспечение транзакционности вносимых изменений и максимизация скорости их выполнения. Именно эти требования определили выбор реляционных систем управления базами данных (далее - СУБД) и модели представления данных «сущность-связь» в качестве основных используемых технических решений при построении учетных систем.
С другой стороны, для поддержки принятия управленческих решений руководителями объектов МЧС России в современных условиях требуются системы, позволяющие [1]:
— интегрировать данные из различных регистрирующих систем с возможностью устранения недостатков, мешающих их последующему анализу (ошибок, пропусков, противоречий, дубликатов и др.);
— вести аналитическую обработку больших объемов «исторических» (накопленных за продолжительный период времени) данных с целью выявления новых, не тривиальных, практически полезных и доступных к интерпретации знаний по деятельности объекта МЧС России (взаимосвязей, закономерностей, тенденций и др.);
— выполнять анализ данных во временном аспекте с возможностью формирования нереглакцентированных запросов, дающих возможность получать ответы на нестандартные вопросы, сформированные «на лету»;
— выполнять построение регулярной OLAP (англ. online analytical processing, интерактивная аналитическая обработка) OLAP-отчетности (отчетности, формируемой в режиме реального времени).
Существующие базы данных учетных систем объектов МЧС России в полной мере не обеспечивают выполнение ни одного из перечисленных требований. Таким образом, в рамках функционирования этих объектов актуальной является задача изыскания и внедрения нового подхода к построению баз данных, позволяющего выполнять аналитическую обработку больших объемов хранимых данных, а также формировать OLAP-отчетность в целях получения новых знаний, необходимых для поддержки принятия обоснованных управленческих решений. Один из вариантов решения приведенного выше противоречия (в плане организации системы хранения подлежащих анализу данных) будет рассмотрен в данной статье. Предлагаемый подход основан на использовании технологии хранилищ данных (далее - ХД), которая
может стать адекватной основой для информационной поддержки деятельности, связанной с принятием управленческих решений на основе использования долговременно хранимых данных. Такой подход пока не имеет законченного научно-методического обоснования и не получил практической реализации в рамках деятельности объектов МЧС России.
Постановка задачи исследования может быть сформулирована следующим образом. В целях совершенствования системы информационной поддержки деятельности, связанной с принятием управленческих решений в рамках функционирования объектов МЧС России, требуется выполнить:
— разработку требований к ХД (DW, Data Warehouse) объектов МЧС России;
— анализ вариантов архитектур ХД объектов МЧС России с определением достоинств и недостатков каждой из таких архитектур.
1. Требования к хранилищу данных объектов МЧС России
Исследование опыта проектирования и разработки ХД в различных сферах управленческой деятельности, а также анализ содержания работ [1, 2, 6, 7] позволяет сделать вывод о том, что «коробочных» (созданных для неопределённого круга пользователей и имеющих стандартные для всех пользователей функции) решений в области построения ХД не существует. Каждое создаваемое хранилище является уникальным, ориентированным на модель функционирования конкретного предприятия, организации, отдела и т.д., в нашем случае - на модель функционирования объекта МЧС России.
Исследование особенностей моделей функционирования объектов МЧС России, построенных с использованием методологий функционального моделирования и построения моделей IDEFO, DFD, IDEF3 и описанных в работах [4, 6, 8] показывает, что, несмотря на уникальность каждого ХД, можно выделить следующие общие функциональные требования к любому ХД объекта МЧС России:
— накопление необходимой хронологической информации по деятельности объекта МЧС и управление ее хранением;
— единый формат хранения и обработки данных;
— хранение как детализированных, так и обобщенных (агрегированных) данных;
— исключение возможности изменения ранее добавленных данных (обеспечить только пополнение данных);
— доступ к «историческим» (накопленным за достаточно длительный период времени) данным с соблюдением их хронологии;
— поддержка нерегламентированных сложных запросов, формируемых «на лету» в зависимости от требуемого анализа данных;
— возможность формирования отчетности по деятельности объекта МЧС;
— возможность для конечных пользователей самостоятельно (без помощи программистов) получать нужную аналитическую информацию за нужный хронологический период (или на нужную дату) в нужных разрезах и в нужных форматах.
2. Анализ вариантов архитектур хранилищ данных
2.1. Анализ реляционного подхода к построению хранилищ данных объектов МЧС
В основе реляционной модели ХД лежит разделение данных на две группы - измерения и факты [1]. Измерения - это категориальные атрибуты, наименования и свойства объектов, участвующих в некотором процессе. Они качественно (не количественно) описывают рассматриваемый процесс. Примерами измерений являются ФИО людей, названия городов, наименования подразделений МЧС России и т.д.
Измерения могут быть и числовыми, если какой-либо категории (например, наименованию уровня химической опасности) соответствует числовой код, но в любом случае это данные дискретные, то есть принимающие значения из ограниченного набора.
Факты - это данные, количественно описывающие процесс, непрерывные по своему ха-
рактеру, то есть они могут принимать бесконечное множество значений. Примеры фактов - количество перевезенного гуманитарного груза, сумм,а причиненного ущерба, зарплата сотрудников и т.д.
При использовании реляционной модели ХД измерения хранятся в плоских таблицах (Fact Table) так же, как и в обычных реляционных СУБД, а факты - в отдельных специализированных таблицах (Dimension Tables), иногда называемых справочниками. При этом таблица фактов является основой для связанных с ней (отношением один ко многим) таблиц измерений. Она содержит количественные характеристики объектов и событий, совокупность которых предполагается в дальнейшем анализировать.
На логическом уровне различают две схемы построения реляционные хранилища данных (далее - РХД) - «звезда» и «снежинка» [7]. Выбор схемы для построения реляционного ХД зависит от используемых механизмов сбора и обработки данных. Каждая из схем имеет свои преимущества и недостатки, которые могут проявляться в большей или меньшей степени в зависимости от особенностей функционирования ХД в целом.
При использовании схемы «звезда» центральной является таблица фактов, с которой связаны все таблицы измерений. Таким образом, информация о каждом измерении располагается в отдельной таблице, что упрощает их просмотр, а саму схему делает логически прозрачной и понятной пользователю (Рисунок 1).
Преимущества такой схемы построения ХД [1]: простота модели и ее логическая прозрачность; при выполнении пополнения измерений аналитик работает только с одной таблицей, что обеспечивает простоту данной операции.
Недостатки схемы «звезда»: одинаковые значения измерений могут повторяться несколько раз в одной и той же таблице, что значительно увеличивает время обработки измерений (в 3 и более раз в сравнении с обработкой нормализованной таблицы базы данных, приведенной к третьей и выше нормальной форме); увеличенная вероятность появления противоречий в данных, например, из-за ошибок ввода.
Рисунок 1 Реляционное ХД пожарного отряда МЧС России, построенное но схеме «звезда»
Сосредоточение всей информации об измерении в рамках одной таблицы не всегда является оправданным. Так, если чрезвычайные ситуации объединены в группы (существует иерархия), то необходимо каким-либо способом показать, к какой конкретной группе относится та или иная чрезвычайная ситуация. Это приведет к многократному повторению наименований групп, что вызовет увеличение избыточности и повышение вероятности появления противоречий (если, например, одну и ту же чрезвычайную ситуация ошибочно отнесут к разным группам). Для более удобной работы с иерархическими измерениями может быть использована модификация схемы «звезда», получившая название «снежинка» [6].
Данные одного измерения могут сохраняться не в одной, а в нескольких, иерархически взаимосвязанных таблицах измерений. Если в измерениях реляционного ХД (хотя бы в одном из измерений) есть иерархическая взаимосвязь таблиц, то схема построения такого хранилища будет иметь название «снежинка» (Рисунок 2). В приведенной на рисунке схеме «снежинка» имеется иерархия таблиц Изм_ Насел Пункт > Изм_Район (таблица Изм_ Район называется консольной).
В схеме «снежинка», в отличие от схемы
«звезда», предусматривается возможность работы с иерархическими уровнями, определяющими степень агрегации данных. Так, приведенная на Рисунок 2 схема «снежинка» позволяет работать как с максимально детализированными данными но каждому пожарному расчету отдельно, так и с агрегированным представлением но имеющимся пожарным частям (с соответствующей агрегацией фактов).
Преимущества схемы «снежинка» [1|:
— в связи с тем, что все значения измерений повторяются только один раз, компактность представления данных существенно выше, чем в схеме «звезда»;
— схема максимально приближена к представлению данных в многомерной модели;
— существенное снижение вероятность появления несоответствия данных и ошибок;
Недостатки схемы «снежинка»:
— сложная для понимания и реализации структура представления данных;
— усложнение технологии добавления значений измерений.
Рисунок 2 Модель реляционншх) ХД пожарншх) отряда МЧС России, поетроенншх) но схеме
«снежинка»
В целом можно выделить следующие преимущества реляционных ХД, построенных но двум приведенным выше схемам:
— отсутствие ограничений на объем загружаемых данных;
— при добавлении новых измерений нет необходимости выполнять перестройку все!'о хранилища данных;
— ввиду хорошей математической основы и распространенности реляционных моделей данных обеспечивается высокая защищенность хранимых данных от несанкци-онированншх) доступа.
Главным недостатком реляционных ХД является увеличение числа иерархических уровней (иерархически взаимосвязанных таблиц), что ведет к существенному снижению скорости выполнения аналити чееких запросов.
По результатам исследований, выполненных в работах [1, 3, 5], можно сделать вывод о том, что реляционную модель построения ХД для объекта МЧС России следует выбирать в следующих случаях:
— предусматриваются большие объемы хранения как детализированных, так и агрегированных данных (в этом случае при-
менение мно!'омерно!'о ХД, которое будет рассмотрено ниже, неэффективно);
— возможна простая иерархия измерений (мало детализированных данных);
— предполагается частая смена размерности данных (в реляционной модели возможность такой смены обеспечивается простым добавлением новых таблиц, а в многомерной модели сложной перестройкой всей структуры ХД).
2.2. Анализ многомерного подхода к построению хранилища данных объектов МЧС России
Как и в случае реляционной модели хранилищ данных, базовыми понятиями мнш'омер-ной модели ХД являются измерения и факты. Однако в мнш'омерной модели данные хранятся не в виде плоских таблиц, а в виде так называемых кубов [1|. Мнш'омерная модель данных может быть представлена в виде системы координат, координатными осями которой являются измерения (например, «Класс пожара», «Пожарная часть», «Дата»). По осям такой системы координат откладываются значения измерений (например, «Класс А», «ПЧ-2», «Февраль») (Рисунок 3). Если измерений три (а их может быть и больше), то на пересечении каж-
дои тройки значений этих измерений находит- ных пожаров определенншх) класса, число вы-
ся точка (ячейка) в пространстве, где размеща- ездов на пожары определенншх) класса, сумма
ются непрерывные (числовые) данные, называ- материальншх) ущерба от пожаров определен-
смыс фактами (например, количество потушен- ншх) класса).
Класс пожара
Рисунок 3 Измерения и факты многомерной модели данных (куба)
На Рисунке 4 показан пример ячеек куба, чеетво потушенных пожаров, число выездов на
в каждой из которых размещены факты, ха- пожары, сумма материальншх) ущерба) но по-
рактеризующие параметры деятельности кон- жарам класса А, тушением которых занималась
кретной пожарной части. Так, в выделенной на пожарная часть ПЧ-2 в марте. Рисунок 4 ячейке расположены факты (коли-
Риеунок 4 Данные о работе подразделения «Пожарная часть 2» в марте по пожарам класса «А»: количество потушенных пожаров, число выездов на пожары, общая сумма материальншх)
ущерба от пожаров класса «А»
Как уже отмсча.лось, многомерная модель представления данных позволяет получать факты и более чем но трем измерениям. В том случае, если измерений будет больше трех, то система измерений будет представлять собой не
куб, а гиперкуб. Например, добавив в рассматриваемом нами примере еще одно измерение «География», имеющее атрибуты «Воронеж», «Липецк», «Орел», мы получим гиперкуб, представленный на Рисунок 5.
Рисунок 5 Отображение гиперкуба
Важно отметить, что не следует сравнивать понятие многомерного куба с геометрической фигурой куб. Понятие «многомерный куб» представляет собой служебное понятие (термин), с использованием которого производится описание техники представления данных, а не фигуру из области геометрии.
Важным достоинством такой модели ХД является то, что в процессе поиска и извлечения из куба (гиперкуба) нужной информации над его измерениями можно производить ряд действий, наиболее типичными из которых являются: сечение (срез), транспонирование, свертка, детализация.
Под сечением (срезом) понимается подмножество многомерного массива данных, соответствующее единственному значению одного или нескольких элементов измерений, не входящих в это подмножество. Иначе говоря, это выделение подмножества ячеек многомерного массива (куба или гиперкуба) при фиксировании значения одного или нескольких измерений. Результатом выполнения сечения является один или несколько срезов данных. Каждый такой срез включает данные, связанные со значением измерения, но которому он был выполнен (Рисунки 6-7).
Рисунок 6 Горизонтальный срез по классу пожара и по дате при фиксированном значении
пожарной части
Рисунок 7 Вертикальный срез но пожарной части и времени при фиксированном значении
класса пожара
Транспонирование (вращение) (Рису- ния измерений, что улучшает наглядное отоб-нок 8) позволяет менять варианты предетавле- ражение данных.
Рисунок 8 Процедура транспонирования
В случае, если имеет место иерархическая подчиненность значений измерений, возможны такие операции над измерениями, как свертка (группировка) и детализация (декомпозиция).
Свертка (Рисунок 9) характеризуется тем,
что индицируемые значения измерений заменяется более обобщенными, вышестоящими значениями измерений. Возрастает степень обобщенности данных.
Например, если какие-то из вредных веществ входят в хрупну «Высоко опасные», то в результате свертки вместо наименований от-
дельных вредных веществ будет указано наименование группы (Таблицы 1-2).
Таблица 1 - Исходная таблица
Группа Опасные вещества Концентрация
Высоко опасные Оксиды азота 10000
Бензол 12000
Иод 4000
Марганец 7000
Умеренно опасные Ацетон 1000
Ксилол 7000
Сернистый ангидрид 2000
Метиловый спирт 500
Таблица 2 - Результат свертки исходной таблицы по измерению «Опасные вещества»
Группа Концентрация
Высоко опасные 33000
Умеренно опасные 10500
Большинство задач аналитической обработки данных, например, задача прогнозирования, требует использования данных определенной степени обобщения. Так, количество аварийных ситуаций определенного класса, учтенных по дням, могут дать очень неравномерный ряд данных, что затруднит выявление характерных периодов, закономерностей или тенденций. Однако если обобщить эти данные в пределах недели или месяца и взять сумму, среднее, максимальное и минимальное значения за соответствующий период, то полученный ряд может оказаться более информативным. Процесс обобщения детализированных данных называется группированием или агрегированием, а сами обобщенные данные - агрегатами.
Агрегаты (они являются непрерывными, т.е. числовыми данными) вычисляются и хранятся в хранилище данных совместно с детализированными данными. Один набор детализированных данных может являться источником нескольких наборов агрегированных данных. В связи с тем, что степень обобщения этих агрегированных данных может быть различной, общий объем данных, находящихся в базах данных, существенно возрастает. Например, набор, содержащий данные о ежедневных замерах уровня радиации в течение года, кроме своих 360 значений, порождает 52 значения с агрегацией по неделям и 12 - по месяцам. Если при этом вычисляются все виды агрегации - сум-
ма, среднее, максимальное и минимальное значения за соответствующий период, - то количество хранящихся агрегированных значений составит уже (52 + 12) * 4 = 256.
В некоторых случаях это приводит к «лавинообразному», неподконтрольному разрастанию хранилища данных и вызывает значимые технические проблемы: хранилище как бы «раздувается», из-за того, что непрерывный поток входных данных автоматически группируется (агрегируется) в соответствии с имеющимися в хранилище данных настройками. Однако с таким положением дел приходится мириться: если бы агрегированные данные не содержались в хранилище данных, а вычислялись в процессе выполнения запросов, время выполнения запроса увеличилось бы в несколько раз [1]. Детализация представляет собой обратную свертке процедуру. Уровень обобщения данных при выполнении этой процедуры уменьшится. Значения тех измерений, которые находятся на более высоком иерархическом уровне заменятся одним или несколькими значениями измерений более низкого уровня. В нашем случае вместо названия группы вредных веществ на индикацию будут выведены названия отдельных вредных веществ и соответствующие им менее обобщенные факты.
Достоинства многомерного подхода:
— более наглядное, чем в реляционной модели, представление данных (в структуре нормализованных таблиц реляционной модели данных может разобраться только администратор хранилища данных);
— более широкие возможности но выполнению различных аналитических запросов;
— уменьшение времени поиска данных (в некоторых случаях в 5 и более раз) и обеспечение выполнения большинства аналитических запросов в режиме реального времени.
Недостатки использования многомерной модели ХД:
— требуемый больший объем памяти для хранения данных, обусловленный увеличением объемов агрегируемых данных и времени на их загрузку (подсчет агрегатов для нескольких Мб исходных данных может увеличить объем хранимых данных в 200 и более раз, т. с. до 2-3 ГБ; при этом степень «разбухания» данных при расчете агрегатов зависит от числа измерений многомерного куба, а также от структуры этих измерений).
А
Как правило, в гибридном ХД агрегированные данные сосредоточены в многомерной структуре, которая обеспечивает высокую скорость выполнения аналитических запросов, а детализированные данные в реляционной, позволяющей загружать неограниченные объе-
— трудности при выполнении модификации многомерной модели.
2.3. Анализ системв1 хранения даннвгх на основе применения технологии гибрид-нвгх хранилищ даннвгх
Реляционные и многомерные модели ХД имеют свои достоинства и свои недостатки. Одним из главных недостатков многомерной модели является то, что при существенном выигрыше в скорости выполнения различных аналитических запросов она имеет ограничения по объему хранимых данных. Реляционная модель, напротив, не имеет ограничений по управлению большими объемами хранимых данных, но является более медленной в плане выполнения сложных аналитических запросов.
Естественно, что многие исследователи задавались целью создать такую новую модель хранилищ данных, которая объединяла бы в себе достоинства как реляционного, так и многомерного подходов. И такая модель была создана [6]. В созданной модели сочетается как высокая производительность, свойственная многомерной модели, так и возможность хранить неограниченно большие объемы данных, присущая реляционной модели. Созданная модель получила название гибридной (Рисунок 10).
1
мы хранимых данных. Приведем пример. Пусть в системе мониторинга параметров опасных загрязнений атмосферного воздуха в регионе ежедневно регистрируются тысячи замеров.
Рисунок 10 Гибридная структура хранилища данных
Регистрация производится с максимальной детализацией регистрируемых данных, к которым относятся:
— характеристики источников выброса (населенный пункт региона, размеры, высота);
— названия вредных веществ, выбрасываемых в атмосферу;
— класс опасности вредных веществ;
— количество загрязняющих веществ, выбрасываемых в атмосферу;
— интенсивность выбросов;
— параметры выбросов.
Вся получаемая таким образом оперативная информация, состоящая из детализированных данных, консолидируется в реляционной структуре ХД. Однако для целей анализа такая детальная информация мало пригодна. Куда больший интерес для аналитика представляют обобщенные данные, например, данные, сгруппированные по классам загрязняющих веществ, населенным пунктам региона или некоторым интервалам дат. Поэтому исходные детализированные данные целесообразно агрегировать и в дальнейшем такие агрегаты сохраняются в многомерной структуре гибридного ХД.
К недостаткам гибридной модели ХД можно отнести усложнение процесса администрирования ХД. Это связано с необходимостью организации более сложного регламента загрузки пополнения хранилища (нужно производить согласование изменения в реляционной и многомерной структурах).
Преимуществом гибридной модели ХД является то, что реляционная модель позволяет формировать устойчивые и непротиворечивые опорные точки для многомерной модели. Кроме того, так как реляционное ХД поддерживает корректность и актуальность данных, оно обеспечивает надежный транспортный уровень
для загрузки данных в многомерное хранилище данных.
Таким образом, в работе выполнено исследование и описание возможных подходов к совершенствованию системы хранения и аналитической обработки данных объектов МЧС России, в том числе и объектов ГО. Рассмотренные подходы основаны на применении технологий реляционных, многомерных и гибридных ХД. Сформулированы обобщенные требования к ХД объектов МЧС России, которые могут стать основой для проектирования и разработки систем хранения и аналитической обработки данных конкретных объектов.
Установлено, что применение многомерной модели ХД позволит как минимум в 2 раза уменьшить время поиска данных по деятельности объекта МЧС России (включая объекты сил ГО) и обеспечит выполнение большинства аналитических запросов в режиме реального времени. При этом за счет необходимости сохранения агрегатов данных объем хранимой в многомерном ХД информации может возрасти в 200 и более раз. Это потребует установления ограничений на общий возможный объем загружаемых в ХД данных. Для исключения такого положения, в рамках большинства объектов МЧС России, целесообразно использовать гибридную модель построения ХД, позволяющую сохранять как большие объемы относительно не часто используемых данных, так и массивы постоянно используемой в повседневной деятельности объекта МЧС России информации. Такой подход обеспечит увеличение скорости информационного обмена в рамках информационных систем поддержки принятия решений объектов МЧС России в три и более раза.
Все вышеизложенные достоинства в полной мере относятся к объектам сил ГО, а значит, будут способствовать повышению эффективности их работы и повышению готовности сил и средств ГО к выполнению существующих и вновь возникающих задач.
Литература
1. Федин Ф.О., Федин Ф.Ф. Анализ данных. Часть 1: Подготовка данных к анализу: Учебное пособие. М.: МПIV. 2012. 204 с.
2. Федин Ф.О., Федин Ф.Ф. Анализ данных. Часть 2: Инструменты Data Mining: Учебное пособие. М.: МГПУ, 2012. 308 с.
3. Федин Ф.О. Комплекс задач аналитической обработки учреждений образования. Наука и мир.2014. Том 1. №2. С. 186-188.
4. Федин Ф.О., Чискидов C.B., Павличева E.H. Разработка модели хранилища данных инновационного предприятия при высшем учебном заведении. Вестник РУДН. Серия: Ин-форматизация образования. 2015. № 1. С. 100-109.
5. Федин Ф.О. Интеллектуальный анализ данных. Часть 1. Учебное пособие. — М: МГПУ. 2015. 100 с.
6. Inmon, Bill, «Building the Data Warehouse», Wiley, ISBN 0-471-56960-7. 1992.
7. Медведева Т. С. Моделирование и разработка информационной системы прогнозирования лесных пожаров [Текст] / Т. С. Медведева, Ф. О. Федин // Научные и образовательные проблемы гражданской защиты. 2016. № 2. С. 59-65.
8. Чискидов C.B. Разработка информационной системы для ведения реестров общественных объединений пожарной охраны и добровольных пожарных [Текст] /C.B. Чисидов, Ф.О. Федин / / Научные и образовательные проблемы гражданской защиты. 2016. № 1 (28). С. 78-83.
