ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ
ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ
ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«Национальный исследовательский университет
«Высшая школа экономики»
Факультет бизнес-информатики
Кафедра бизнес-аналитики
ВЫПУСКНАЯ КВАЛИФИКАЦИОННАЯ РАБОТА
На тему
«Построение хранилища данных для анализа
авиаперевозок на территории России»
Студент группы № 473
Смоленцев А. И.
Научный руководитель
к.т.н., доцент Герасимов Н. А.
Рецензент
преподаватель, Периков Ю. А.
Москва, 2013
ОГЛАВЛЕНИЕ
Введение
4
Глава 1. Анализ проблем авиатранспортной отрасли России
7
1. Комплексный анализ положения авиатранспортной отрасли России
7
2. Формулировка основных задач работы
10
3. Анализ инструментария для достижения цели работы
11
Глава 2. Сбор данных для разрабатываемой системы
15
1. Определение модели предметной области
15
2. Поиск данных в различных источниках
18
3. Моделирование данных для разрабатываемой системы
22
Глава 3. Проектирование хранилища данных
и инструментов анализа данных
24
1. Создание модели хранилища данных
24
2. Применение ETL-инструмента
30
3. Применение BI-приложения и моделей data mining
38
Заключение
47
Список использованной литературы
50
Приложение 1
52
Приложение 2
53
2
Аннотация.
В данной выпускной квалификационной работе проиллюстрировано
построение и применение аналитической системы на базе многомерного
хранилища данных для анализа проблем и прогнозирования развития
авиатранспортной системы в России. В работе был осуществлен сбор данных;
затем была спроектирована структура хранилища данных, в которое затем при
помощи ETL-инструментов были загружены собранные данные. В конечном
итоге система произвела анализ данных по авиаперевозкам, благодаря чему
были сделаны некоторые выводы.
Структура работы представлена вводной частью, тремя главами по три
параграфа в каждой, заключением, списком использованной литературы и
двумя приложениями.
Данная работа будет интересна как специалистам, которые занимаются
бизнес-аналитикой, так и другим людям интересующимся развитием и
проблемами российской экономики, в частности в авиатранспортной отрасли.
3
Введение.
Особенностью Российской Федерации является резкое различие уровня
развития регионов в зависимости от их территориальной принадлежности.
Регионы центральной России, такие как Москва и Московская область,
наиболее развиты, в то время как уральские, дальневосточные и южные
субъекты
федерации
обладают
гораздо
меньшими
экономическими
возможностями и в большинстве случаев развиваются (если развиваются
вообще) довольно медленными темпами. Такое положение вещей накладывает
свой отпечаток на производственные и коммерческие сферы деятельности, в
том числе на систему и структуру авиаперевозок в России. Авиатранспортная
сеть страны покрывает огромную территорию и включает в себя более 125
функционирующих аэропортов. Бóльшая доля потоков в этой отрасли
проходит через московский транспортный узел (МТУ), что указывает на
централизованное развитие структуры транспортных маршрутов. Примерные
соотношения средних исходящих грузовых потоков за месяц для десяти
лидирующих по этому показателю городов России (2010-2011 гг., по данным
ТКП) представлены на иллюстрации ниже [12].
7000
6000
5000
4000
3000
Исходящий грузовой
поток, тонн
2000
1000
0
Иллюстрация 1: Среднемесячный исходящий грузопоток, тонн
По
данным
наглядно
видно,
что
4
Москва
обгоняет
ближайшего
преследователя (Санкт-Петербург) более чем в 10 раз. Таким образом, на базе
МТУ сформировался торгово-распределительный центр для всей страны. Для
такой большой страны, какой является Россия, такое несбалансированное
распределение мощностей играет неблагоприятную роль и является серьезной
структурной проблемой.
Очевидно, что тема развития или же реструктуризации авиатранспортной
отрасли Российской Федерации заслуживает внимания. В данной работе
предпринимается попытка решить проблемы, имеющие место в данной
отрасли.
Основная цель работы заключается в построении хранилища данных,
благодаря
которому
будет
возможно
проанализировать
развитие
авиаперевозок в России за некоторый период времени, спрогнозировать их
объемы в будущем, а самое главное — предложить альтернативную структуру
авиатранспортной сети.
В качестве инструментария для выполнения этой задачи в работе
предлагается
использование
технологий
Data Warehousing
/
Business
Intelligence (DWH/BI).
Данная работа предполагает следующий поток выполнения работ для
достижения поставленной цели:
1. Комплексный анализ положения авиационной отрасли для выявления
особенностей моделирования предметной области для исследования.
2. Формулировка конкретной задачи и формирование четкого плана
выполнения работ в разрезе информационных технологий.
3. Анализ программных средств, имеющихся на рынке, для каждого из
этапов реализации технологий BI/DWH, а именно: этап «проектирование
хранилища данных на основе определенной СУБД (системы управления
базами данных)», этап «извлечение данных из источников в хранилище
данных», этап «реализация инструментов анализа и визуализации данных».
4. Создание
абстрактной
проанализированной
модели
информации
предметной
на
5
этапе
области
с
учетом
комплексного
анализа
авиатранспортной отрасли.
5. Определение источников информации об авиационной отрасли и
извлечение данных из этих источников.
6. Моделирование недостающих данных из-за их отсутствия в открытом
доступе на основе других немаловажных факторов регионального развития с
учетом сезонности авиаперевозок.
7. Проецирование модели предметной области на модель хранилища
данных, имеющего форму «Звезда» (Star-Schema) с учетом особенностей
СУБД.
8. Реализация механизма extract-transform-load (ETL) для переноса данных
из различных источников в хранилище данных.
9.
Применение инструментов интеллектуального анализа и моделей data
mining на основе хранилища данных для получения выводов и заключений по
проблеме работы.
6
Глава 1. Анализ проблем авиатранспортной отрасли России
1.
Комплексный анализ положения авиатранспортной отрасли
России.
Как отмечалось во вводной части данной работы, авиатранспортная сеть в
России является централизованной и несбалансированной. Эта ситуация
неблагоприятна для экономики как отдельных регионов, так и страны в целом.
Вопрос несовершенности авиатранспортной структуры уже поднимался
неоднократно, причем доклады, исследования и предложения звучали как со
стороны государственных органов, так и со стороны коммерческих
организаций, являющихся участниками рынка авиаперевозок. Также интерес к
проблеме проявляет академическая среда, и
даже коммерческий сектор
экономики, никак напрямую не увязанный с авиаперевозками. Все эти
стороны рассматривают и анализируют проблему с разных точек зрения, что
позволяет получить целостную картину происходящего в отрасли.
В докладе «Некоторые аспекты региональных авиаперевозок» [12]
генерального
директора
авиакомпании
«Полет»
на
Международном
Авиатранспортном Форуме автор демонстрирует, насколько велик дисбаланс
грузоперевозок между МТУ и другими регионами. Также докладчик
акцентируется на односторонности потоков грузов, на очень маленьких
объемах
грузопотоков
между
отдельными
регионами,
на
высокой
конкуренции авиационного транспорта с другими видами — автомобильным
и железнодорожным. Также автор ссылается на данные по плотности
населения по федеральным округам, данные по количеству складских
площадей в регионах, а также на данные по входящим и исходящим
грузопотокам в разных городах России. Один из выводов доклада говорит о
том, что в ближайшее время не ожидается перераспределения потоков и
уменьшения дисбаланса между потреблением в центральной части России
(особенно в столице) и в восточных регионах.
Взгляд
на
проблему
с
точки
7
зрения
академической
среды
проиллюстрирован в работе «Анализ состояния и развития авиатранспортной
системы (в России)» [11]. Автор работы неоднократно указывает на
плачевность состояния аэродромной сети в России, приводя ряд интересных
статистических данных, например «количество действующих аэропортов на
территории Российской Федерации, начиная с 1991 года по настоящее время,
сократилось с 1450 до 351» или «в целом износ основных фондов
аэродромной сети приблизился к 80%» (касательно только региональных
аэропортов). Среди выводов в работе фигурирует идея о том, что именно
государство должно заниматься решением проблемы, в том числе бороться с
инфраструктурной непригодностью региональных аэропортов.
На государственном уровне проблема также рассматривается, причем уже
есть некоторые результаты. Министерство транспорта РФ внесло в
правительство проект «дорожной карты» [13] развития региональных
авиаперевозок до 2030 года, что позволило бы решить множество проблем в
отрасли. В задачи проекта входит, например: финансовое обеспечение
аэропортов, разработка стандарта минимальной транспортной доступности,
совершенствование государственного регулирования, а также снижение
стоимости региональных авиаперевозок. В целом, задачи проекта очень
актуальны для отрасли. Вопрос в том, будут ли они реализованы в полной
мере, и в какие сроки все это будет сделано.
Также нужно отметить статью «Бизнес-модель развития грузовых
авиаперевозок в Российской Федерации» [10], авторы которой акцентируются
на транспортных взаимоотношениях с другими странами. В статье говорится
о потенциальных возможностях российской авиационной структуры по
отношению
к
зарубежным
перевозчикам,
то
есть
о
транзитных
взаимоотношениях. Авторы пишут, что для реализации такого потенциала
необходимо внедрение стандарта e-freight, а также усовершенствование
(расширение) аэродромной сети, упрощение процедур приема и изменение
нормативно-правовой базы по данному вопросу. Центральным аспектом
является как раз расширение аэродромной сети России, другими словами —
8
переход от централизованной системы к распределенной: с несколькими
«хабами» для более эффективной работы сети.
Из всей приведенной выше информации можно сделать вывод о том, что
на сегодняшний день аэропортная сеть в России представляет собой
централизованную структуру с серединой в московском транспортном узле, в
то время как региональные аэропорты и аэродромы в большинстве случаев
характеризуются неразвитостью, отсутствием надлежащей инфраструктуры и
чрезвычайно сильным износов оборудования. Также нужно отметить, что
больше половины транспортных потоков по воздуху проходят через МТУ,
причем товарные потоки между регионами несоизмеримо малы. Если
учитывать
территориальную
обширность
России,
то
такая
несбалансированная ситуация в отрасли недопустима. Абстрактно ситуация
может быть представлена, как показано на иллюстрации ниже.
Иллюстрация 2: Абстрактная схема текущей структуры авиаперевозок
России
9
2. Формулировка основных задач работы.
В данной работе лишь предпринимается попытка проанализировать
авиатранспортную отрасль России в разрезе авиатранспортных потоков при
помощи изученных инструментов анализа данных, относящихся к концепции
Business Intelligence.
К
сожалению,
очень
малая
доля
информации
относительно
авиатранспортных потоков находится в открытом доступе, особенно в разрезе
временной динамики и в разрезе территориальной принадлежности. Поэтому,
разрабатываемая система будет реализована на смоделированных данных,
основанных
на
реальных
экономических
показателях.
Сбору
и
моделированию данных в данной работе будет посвящена отдельная часть.
Из комплексного анализа проблемы следует то, что в первую очередь
необходимо
сфокусироваться
на
определении
доли
московского
транспортного узла в общем объеме авиатранспортных перевозок по России.
Первая важная задача в работе — это определение этой доли и динамики её
изменения за определенный период времени.
Также было бы интересно узнать, какая динамика развития отрасли будет
наблюдаться в будущем. Из этого вытекает вторая важная задача работы —
прогнозирование объемов авиатранспортных потоков в будущем.
Немаловажно также сделать попытку предложить вариант решения
проблемы несбалансированности авиатранспортной системы в России.
Решение этой проблемы является третьей важной задачей работы.
Как было отмечено выше, попытка решения всех важных задач работы
должна быть реализована при помощи инструментов анализа данных,
существующих на сегодняшний день на рынке IT-решений.
10
3.
Анализ инструментария для достижения цели работы.
Так как в цели работы входит построение хранилища данных для анализа
авиатранспортной системы России, то в первую очередь необходимо
произвести обследование рынка компонентов хранилищ данных для более
эффективной и удобной работы в процессе исследования.
Концепция BI/DWH, которая будет применяться в работе, предполагает
наличие нескольких компонентов:

Внешние источники данных. В качестве внешних источников в работе
будут выступать файлы различных форматов, содержащие в себе собранную и
смоделированную информацию по авиатранспортной отрасли России.

ETL-инструмент, который поддерживает процедуры извлечения данных из
внешних источников, их преобразования и дальнейшей загрузки в хранилище
данных.

Хранилище данных, в которое производится загрузка данных из внешних
источников при помощи ETL процедур. Хранилище представляет собой
предметно-ориентированную информационную базу данных, специально
разработанную и предназначенную для подготовки отчётов и бизнес-анализа с
целью поддержки принятия решений в организации. Хранилище данных
реализуется в системе управления базами данных (СУБД).

Инструменты интеллектуального анализа. Они обеспечивают анализ
данных, хранящихся в хранилище данных. Основная цель интеллектуального
анализа данных состоит в обеспечении необходимой информацией того круга
лиц,
которому
эта
информация
необходима
для
принятия
важных
управленческих решений или для решения других важных задач. Информация
может быть представлена в форме отчетов, информационных панелей,
визуализированных данных и т. д.
Обобщенная схема концепции представлена на иллюстрации 3:
11
Иллюстрация 3: Общая схема Business Intelligence
В данном параграфе будет сделан обзор инструментов по 3 направлениям:

ETL;

СУБД;

Инструменты анализа.
На рынке существует большое количество как платных, так и бесплатных
ETL-инструментов и
инструментов интеграции
данных. Ниже
будут
рассмотрены 3 решения: Microsoft SQL Server Integration Services (MSSIS),
Oracle Warehouse Builder (OWB) и Pentaho Data Integration (PDI).
OWB [18] входит в семейство продуктов Oracle Developer Suite и
представляет собой интегрированную CASE-среду, предназначенную для
разработки и развертывания хранилищ и витрин данных. Средствами этого
продукта можно проектировать, создавать и администрировать хранилища и
витрины данных, разрабатывать и генерировать процедуры извлечения,
преобразования и загрузки данных из различных источников, управлять
метаданными. Плюсы: наглядность проектирования, стандартизованность,
мультиплатформенность, управляемость компонентами хранилища данных,
12
многофункциональность. Минусы: сложность при установке системы,
возможна несовместимость с некоторыми программами, высокие системные
требования.
Службы Integration Services [17] представляют собой платформу для
построения высокопроизводительных решений интеграции данных и решений
потока операций, включая операции извлечения, преобразования и загрузки
(ETL) для хранилищ данных. Плюсы: большой объем документации,
поддержка продукта, относительно небольшая цена, визуальные средства
разработки. Минусы: возможна сложность в организации логики ETL
процесса, продукт ориентирован только на одну.
PDI - это компонент комплекса Pentaho [19] отвечающий за процессы
Извлечения, Преобразования и Загрузки данных в целевую систему (ETL).
Несмотря на то, что использовать системы ETL предполагается в рамках
комплекса хранения данных, средства PDI могут быть применены и для
других целей: обмена данными между приложениями или базами данных,
экспорта данных из таблиц баз данных в файлы, загрузки массивов данных в
базы данных, обработки данных, интеграции в приложения. Плюсы:
бесплатная система, понятный графический интерфейс (именуемый Spoon),
многофункциональность, мультиплатформенность, легкость в инсталляции.
Минусы: в системе есть недостатки, связанные с тем, что продукт является
open source.
В данной работе будет использоваться инструмент Pentaho Data Integration,
т. к. он является бесплатным и наиболее понятным в использовании. К тому
же в отличие от SSIS в PDI имеются возможности предварительного
просмотра объектов в источнике данных, прогона трансформаций в тестовом
режиме, а также вывода системных уведомлений. К тому же SSIS не
располагает такими возможностями как PDI при извлечении информации из
файлов различных типов. Функционал этого продукта достаточен для
реализации задач, поставленных в работе.
13
При выборе СУБД рассматривались 3 варианта. Это Microsoft Sql Server
2008, MySQL и Oracle 11g. Несмотря на то, что Microsoft Sql Server [17]
работает только под операционной системой Windows, выбор пал именно на
этот продукт. Это обуславливается тем, что СУБД от Microsoft с одной
стороны обеспечивает наибольшую надежность и безопасность, что особо
заметно при сравнении с MySQL, а с другой стороны MS Sql Server не
настолько дорогая, как Oracle. К тому же СУБД от Microsoft обладает таким
функционалом, который является достаточным для решения поставленной в
работе задачи. Также, что немаловажно, эта СУБД тесно интегрируется с
продуктами Microsoft Office. Другой отличительной чертой MS Sql Server
является собственная разработка всей линейки продуктов в отличие от
компании
Oracle,
линейка
продуктов
которой
была
создана
путем
приобретения, что требует усилий по интеграции всех компонентов в одну
систему.
Поскольку в качестве СУБД была выбрана разработка компании Microsoft,
то интеллектуальный анализ данных было решено проводить на базе
продуктов от этой компании. Это обуславливается тем, что MS Sql Server
прекрасно интегрируется с продуктами для бизнес-анализа от Microsoft, а
также функции, которые реализуются в данных продуктах, соответствуют
задачам работы. В инструменте предусмотрены встроенные модели data
mining
[9],
которые
позволят
проводить
прогнозный
анализ
по
авиатранспортной отрасли, а также реализовывать другие требуемые задачи.
Итак, в качестве ETL-системы был выбран продукт Pentaho Data
Integration, в качестве СУБД — MS Sql Server 2008, а в качестве инструментов
анализа — MS Sql Server Analysis Services.
14
Глава 2. Сбор данных для разрабатываемой системы
1.
Определение модели предметной области.
В данной части работы предполагается создание абстрактной модели
предметной области с учетом проанализированной информации на этапе
комплексного анализа авиатранспортной отрасли.
Как отмечалось ранее, авиатранспортная сеть России представляет собой
несбалансированную структуру с центром в МТУ. Также отмечалось, что
наблюдается тенденция ежегодного увеличения доли МТУ в общем
авиатранспортном трафике по России. Из всего этого следует, что
разрабатываемый
комплекс
должен
учитывать
изменения
объемов
авиатранспортных потоков, как минимум, в разрезах «территориальная
принадлежность» и «время». Таким образом, можно абстрагироваться от
описания конкретных аэропортов, а взять Регион за базовую единицу разреза
«территориальная принадлежность», например, Омская область. Из анализа
данных по регионам будет нагляднее понятно, какие территории претендуют
на развитие в крупных городах «распределительных узлов» или, другими
словами, «хабов». Родительским элементом для объекта «Регион» является
«Федеральный округ», который включает в себя несколько регионов. Также у
каждого региона есть свой региональный центр.
Отчетность по объемам перевозок происходит поквартально. Это тоже
важно учитывать при проектировании хранилища данных в будущем.
Ключевым объектом в предметной области является «Авиаперевозки для
региона», который, в свою очередь, подразделяется на Входящий поток и
Исходящий поток. Каждый экземпляр этого абстрактного объекта имеет
территориальную принадлежность и временную отметку, объем перевозки.
Также не стоит забывать о таком понятии, как Авиакомпания. В
проектируемой предметной области оно есть. Также стоит разделять
перевозки на Пассажирские, Грузовые и Перевозки почты.
15
По данному описанию в предметной области можно выделить следующие
сущности:
1. Авиаперевозки для региона (с типом перевозки, временной отметкой и
направлением авиационного потока)
2. Федеральный округ
3. Регион
4. Авиакомпания
В таблице 1 представлены сущности и их атрибуты:
Таблица 1: Описание сущностей и их признаков
Имя сущности
Признаки
Авиаперевозка
Дата, тип перевозки, направление (вход/выход), регион,
авиакомпания, объем перевозки
Авиакомпания
Название, другие особенности
Федеральный округ
Наименование, федеральный центр
Регион
Принадлежность к федеральному округу, наименование,
региональный центр
В таблице ниже представлены отношения сущностей:
Таблица 2: Описание отношений между сущностями
Сущность №1
отношение
действие
Сущность №2
Федеральный округ
1:M
Включает в себя
Регионы
Авиакомпании
М:М
Совершают рейсы по
Регионам
различным
Авиакомпания
1:М
Имеет много
Авиаперевозок
Авиаперевозки
М:1
Принадлежат к
Региону
определенному
В разрабатываемой системе не ставится задача рассмотреть
авиаперевозки в разрезе авиакомпаний. Но такая сущность вносится в систему
для возможного дальнейшего развития проектируемого аналитического
программного комплекса. Также необходимо отметить, что в системе
фигурируют только Грузовые авиаперевозки. Разделение на виды перевозок
16
также вводится в систему с перспективой на дальнейшее развитие.
17
2.
Поиск данных в различных источниках.
Коллекционирование данных является основой любого исследования. В
данном исследовании необходима информация, в первую очередь, об объемах
входящих и исходящих авиаперевозок в регионах России за 2005-2011 годы.
Эта информация не доступна в открытых источниках, следовательно, эти
данные будут смоделированы на основе других показателей развития в
регионах России. В качестве таких показателей были взяты:
1. численность населения;
2. валовый региональный продукт (ВРП);
3. уровень экономической активности населения.
Эти данные были собраны для 32 крупнейших городов из 29 различных
регионов за период с 2005 по 2011 год. Ниже представлен перечень регионов,
по которым собирались данные:
Таблица 3: Рассматриваемые в системе регионы
Московский регион*
Ленинградский регион*
свердловская область
ханты-мансийский а. округ
(Югра)
хабаровский край
тюменская область
приморский край
республика Дагестан
красноярский край
ростовская область
ярославская область
ивановская область
новосибирская область
алтайский край
иркутская область
пермский край
камчатский край
самарская область
сахалинская область
республика Башкортостан
краснодарский край
нижегородская область
республика Саха (Якутия)
республика Татарстан
магаданская область
омская область
челябинская область
18
волгоградская область
воронежская область
* Примечание. Московский регион объединяет в себе федеральные
субъекты «Москва» и «Московская область». Аналогично и с ленинградским
регионом.
Также важно отметить, что некоторые значения коэффициентов и
параметров, введенные в данной главе, не являются результатом применения
математических
моделей.
Они
предлагаются
исходя
из
разумных
предположений. Данное допущение возможно, т. к. в работе предполагается
построение системы анализа авиаперевозок, которая в свою очередь не
нуждается в высокой достоверности данных, потому что является всего лишь
инструментом исследования.
Регионы отбирались по следующему принципу: во-первых, были взяты
регионы, на территории которых есть города-миллионники. Во-вторых,
брались регионы с максимальным исходящим авиационным грузопотоком в
2011 году по статистике Торговой Клиринговой Палаты (ТКП, www.tch.ru) [16].
Для каждого из вышеперечисленных регионов были найдены различные
экономические показатели за период с 2005 по 2011 год. Чтобы как-то
диверсифицировать данные показатели по значимости, были предположено,
что каждому показателю соответствует определенный коэффициент. Сумма
коэффициентов получается равной единице. Данные коэффициенты не
рассчитывались при помощи математических или экономических моделей;
они были предложены автором работы из соображений здравого смысла.
Во-первых, была собрана статистика по численности населения за
указанный период. Источником послужили базы Федеральной службы
государственной статистики (www.gks.ru) [15]. Численность населения — это
важнейший показатель экономического развития страны. Поэтому данному
фактору присвоен коэффициент значимости 0,4 из 1.
Примечание. Коэффициенты значимости будут использоваться при
19
моделировании данных.
Вторым, не менее важным показателем развития в регионах, данные по
которому были собраны в рамках исследования, это региональный валовый
продукт. Валовой региональный продукт представляет сумму валовой
добавленной стоимости, созданной всеми институциональными единицамирезидентами на экономической территории региона (без учёта чистых налогов
на продукты). Уровень значимости для исследования — 0,4 из 1. Источник —
www.gks.ru [15].
Третья величина, от которой в некоторой степени зависит развитие
региона, - это уровень экономической активности населения. Этот показатель
представляет собой процент активного населения от общей численности
региона. Например, в 2011 году в Московском регионе этот показатель
составил 72,2. Значимость этого показателя не так велика, как значимость
предыдущих двух показателей. Поэтому коэффициент значимости был взят
равным 0,2 из 1. Источник — www.gks.ru. [15]
Также
была
собрана
информация
о
суммарном
внутреннем
авиатранспортном грузовом обороте за 2005-2011 годы. Источник — ТКП
[16]. В таблице 4 представлены собранные по этому пункту данные:
Таблица 4: Ежегодный объем авиатранспортных потоков в России
2005
197,19
2006
2007
202,94 231,67
2008
2009
245,08
224,01
2010
2011
291,02
306,34
тыс. тонн
Дополнительно были введены коэффициенты оттока и притока грузов для
каждого региона. Они нужны для того, чтобы при моделировании
распределить общий грузооборот в регионе на исходящие и входящие
грузопотоки. Например, если в регионе за 2005 год общий оборот грузов
равняется 10 тыс. тонн, а коэффициент оттока товаров равняется 60%, то
исходящий грузопоток получается равным 6 тыс. тонн, а входящий — 4 тыс.
тонн. Эта величина введена на основе приблизительных предположений, и,
так как в исследовании не важна высокая точность и правдоподобность
20
данных, её использование вполне оправдано для получения нужной
информации.
Помимо данных, которые необходимы для формирования объемов
авиатранспортных потоков, была собрана контекстная информация, которая
будет отражена в разрабатываемой системе. В таблице ниже приведен
перечень блоков собранных данных с указанием файлов, в которые эти
данные были сохранены.
Таблица 5: Соответствие блоков данных файлам
Наименование блока данных
Имя файла
Перечень регионов с указанием регионального центра и
федерального округа
Места.csv
Виды авиатранспортных перевозок
DirAndType.xls
Направления авиатранспортных перевозок
DirAndType.xls
Перечень авиакомпаний
Авиакомпании.txt
Особенности использования перечисленной информации будут отражены
в последующих главах.
Следующим этапом работы является моделирование необходимых для
исследования
данных
на
базе
собранных
реальных
показателей.
Смоделированные данные будут записаны в файл Объемы_перевозок.xlsx.
21
3. Моделирование данных для разрабатываемой системы
Этот этап полностью посвящен моделированию данных о поквартальном
объеме входящего и исходящего авиатранспортного грузопотока для 29
регионов России за период с 2005 по 2011 годы.
Весь процесс моделирования можно разбить на 3 этапа: 1 — вычисление
общих коэффициентов для регионов, 2 — вычисление объемов грузопотоков,
3 — разбиение данных в зависимости от сезонных (квартальных)
особенностей.
(1) Вычисление общих коэффициентов. На данном этапе использовались
коэффициенты значимости факторов и значения ранее найденных факторов
для регионов. Формула вычисления общего коэффициента выглядит
следующим образом:
коэфф(m, n)=0,4*(доля региона m в общей численности населения за год
n)+0,4*(доля региона m в суммарном ВРП за год n)
+0,2*(долевой уровень активности населения в регионе m за год n)
В результате получилась таблица [M x N], где в строках находятся данные
по определенному региону за период с 2005 по 2011 год, а в столбцах —
коэффициенты за определенный год относительно всех регионов. В общем
счете таблица содержит 203 значения коэффициента. Эта таблица будет
использована на 2 этапе моделирования — вычислении объемов грузопотоков.
(2) Вычисление объемов грузопотоков. Этот этап основан на созданной на
предыдущем
этапе
таблице
основных
коэффициентов,
а
также
на
коэффициентах оттока и притока грузов и на значениях общего внутреннего
авиатранспортного
грузооборота.
Расчёт
формуле:
22
производился
по
следующей
грузооборот(i/o, m, n)=коэффициент oттока/притока(i/o)
* общий коэффициент для региона m за год n
* общий внутренний авиатранспортный грузооборот за год n
В результате получается таблица размером [M x (N*2)], то есть
содержащая 406 значений входящего и исходящего авиационного грузового
трафика для каждого региона за время в интервале с 2005 по 2011 год.
(3)
Разбиение данных в зависимости от квартальных особенностей. На
данном этапе данные были преобразованы в более детальную форму. При
этом использовались данные о сезонности, взятые из отчета ТКП [16]. Эти
данные представлены в таблице 6:
Таблица 6: Сезонные коэффициенты
Сезонность
1 квартал
2 квартал
3 квартал
4 квартал
2005
0,17
0,25
0,36
0,22
2006
0,17
0,25
0,35
0,22
2007
0,17
0,25
0,35
0,23
2008
0,19
0,27
0,34
0,2
2009
0,17
0,25
0,35
0,24
2010
0,18
0,25
0,34
0,23
2011
0,18
0,24
0,34
0,24
С учетом этих значений объем модельных данных вырос в 4 раза и
составил 1624 значения.
В итоге процесса моделирования были сформирована ненормализованная
таблица со следующими заголовками:
Таблица 7: Макет таблицы для данных
Регио
н
Федераль
ный
округ
Год
(7 столбцов для 2005-2011 годов)
1 квартал
Вход.
Исход.
2 квартал
3 квартал
4 квартал
Вход. Исход. Вход. Исход. Вход. Исход.
Данная таблица содержит 2+7*(4*2)=58 столбцов. Далее вся смоделированная
информация обрабатывается и сохраняется в файле Объемы_перевозок.xlsx.
23
Глава 3. Проектирование хранилища данных и инструментов
анализа данных
1. Создание модели хранилища данных
Модель хранилища данных будет создаваться на основе описания
предметной области, сделанного во 2 главе.
Хранилища
данных
(Data
Warehouse)
представляют
собой
специализированные базы данных, предназначенные для хранения данных,
которые редко меняются, но на основе которых часто требуется выполнение
сложных запросов [2].
Обычно они ориентированы на выполнение
аналитических
которые
запросов,
обеспечивают
поддержку
принятия
решений для руководителей и менеджеров. Хранилища данных позволяют
разгрузить
промышленные
пользователям
более
базы
данных,
эффективно
и
и
быстро
тем
самым
извлекать
позволяют
необходимую
информацию. Как правило, хранилища данных оперируют с огромными
объемами информации, что предъявляет к их проектированию и реализации
повышенные требования.
Существует 4 наиболее распространенных методологии проектирования
хранилища данных:
1. Хранилище данных в 3-НФ (третья нормальная форма) [2]. Структура
представлена в третьей нормальной форме, что значительно снижает скорость
ответа серверов при обработке больших объемов данных. Концепция была
предложена американским ученым в сфере ИТ Биллом Инмоном в 1992 году.
По утверждению Б. Инмона хранилище данных должно проектироваться с
использованием
нормализованной
модели.
К
основным
недостаткам
реляционной модели относятся: (1) сложность для пользователей получить
целостную информацию о бизнес объектах, (2) низкая производительность
при больших объемах данных.
2. Многомерный (Dimensional) подход, предложенный Ральфом Кимбаллом в
24
1996 году [1]. Данная методология является самой распространенной на
сегодняшний день благодаря своей простоте, понятности для пользователей,
производительности. По Кимбаллу хранилище данных представляет собой
денормализованную структуру с таблицей фактов и таблицами измерений.
Факты содержат в себе меры (например, доход, количество, процент) и
суррогатные
ключи
измерений.
Измерения
являются
контекстной
информацией (например, измерение «Клиент», «Магазин») для описания
определенного факта. Однако, возможно возникновение трудностей при
загрузке данных из внешних источников в хранилище в контексте интеграции
данных в таблице фактов и таблицах измерений.
3. Data Vault [22]. Эта методология предполагает наличие трех видов
сущностей в хранилище: узел (hub), спутник (satellite) и link (связь). Узлы
содержат в себе лишь суррогатные ключи, бизнес ключи и информацию о дате
загрузки объекта и об источнике. Все свойства и атрибуты хаба хранятся в
спутниках. Связи отражают взаимоотношения бизнес объектов, описанных в
хабах; они также могут иметь свои спутники. Примеры хаба: Клиент,
Поставщик; примеры спутника: адрес клиента, имя клиента. Примеры связи:
заказ, покупка, поставка. Система, спроектированная по этой методологии,
характеризуется высокой степенью гибкости и масштабируемостью. Также
методология обеспечивает долгосрочное хранение истории о загрузках
объектов и об источниках. Авторы методологии утверждают, что Data Vault
является чем-то средним между проектированием хранилищ данных в 3
нормальной форме (3NF) и проектированием хранилищ данных в форме
«Звезды» (Dimensional). Однако структура Data Vault в некоторых случаях
может оказаться чрезмерно сложной для предприятия, а также могут
возникать проблемы во время применения аналитических инструментов из-за
слишком большого количества таблиц.
4. Entity-Attribute-Value (EAV) или Сущность-Атрибут-Значение [23] — это
методология, основанная на описании сущностей с большим количеством
25
потенциальных свойств (атрибутов), из которых используется лишь некоторая
часть. EAV используется в системах-конструкторах, в которых структуру базу
данных определяет конечный пользователь, например в интернет-магазинах.
Только в таких случаях есть смысл использовать такую модель данных,
характеризующуюся очень высокой гибкостью, масштабируемостью. Но такая
модель данных очень сложна в смысле понимания для разработчиков и
администраторов баз данных, что зачастую является причиной отказа от этой
методологии.
В разрабатываемой в данной работе системе при проектировании
структуры хранилища данных будет применяться методология Р. Кимбалла.
Во-первых,
это
вызвано
тем,
что
инструменты
анализа
наиболее
адаптированы к этой модели, а, во-вторых, данная модель наиболее понятна, и
она будет лучше других подходить в качестве шаблона для описанной
предметной области, а именно: области авиатранспортных потоков на
территории России.
Первым шагом при моделировании структуры хранилища данных
является описание таблиц измерений. Ниже представлены названия таблиц
измерений, их поля с типами данных с учетом специфики выбранной СУБД
(MS SQL Server 2008).
1. Dim_date — временное измерение
Поля:
date_id — идентификатор экземпляра даты (суррогатный ключ)
date_date – дата (начало каждого квартала: например, 1.1.2012, 1.4.2012,
1.7.2012, 1.10.2012)
date_year - год
date_quater – квартал (делать более глубокую детализацию для решения
задачи работы нет смысла. Отчетность идет поквартально)
2. Dim_place — абстракция «регион»
Поля:
26
place_id int primary key, -идентификатор региона (суррогатный ключ)
place_fed_distinct varchar(50), - название федерального округа
place_region varchar(50), - название региона
place_center varchar(50) — региональный центр (название города)
3. Dim_direction — измерение «направление грузового потока»
Поля:
direction_id int primary key, - идентификатор (суррогатный ключ)
direction_title varchar(15), - наименование направления (возможные значения:
входящий поток, исходящий поток)
direction_desc varchar(100) — описание (определение)
4. Dim_transportation_type — измерение «тип авиаперевозки»
Поля:
tr_type_id int primary key, - идентификатор (суррогатный ключ)
tr_type_title
varchar(30),
-
наименование
типа
(возможные
значения:
пассажиры, груз, почта), (В системе будут фигурировать факты только со
значением данного измерения «груз»)
tr_units varchar(20) — единицы измерения
5. Dim_company — измерение «Авиакомпании»
Поля:
company_id int primary key, - идентификатор (суррогатный ключ)
company_title_rus varchar(50), - наименование компании на русском (Как было
отмечено в главе, посвященной описанию предметной области, система не
предусматривает рассмотрение авиаперевозок в разрезе компаний. Все
авиационные
потоки
будут
относиться
к
модельному
экземпляру
авиакомпании с атрибутами (1, компания_модель, company_model, companymodel-site.com).
Данное
измерение
совершенствования системы в будущем)
27
введено
для
потенциального
company_title_eng varchar(50), - наименование компании на английском
company_web_site varchar(50) — веб-сайт компании
После описания всех таблиц измерений следует описать таблицу фактов:
FactTransportation — факт авиаперевозки
Поля:
trans_id int primary key, - идентификатор факта (суррогатный ключ)
date_id int - внешний (суррогатный) ключ к измерению dim_date
place_id int - внешний (суррогатный) ключ к измерению dim_place
direction_id int - внешний (суррогатный) ключ к измерению dim_direction
tr_type_id
int
внешний
-
(суррогатный)
ключ
к
измерению
dim_transportation_type
company_id int - внешний (суррогатный) ключ к измерению dim_company
value real — объем перевозки (например, 1000 пассажиров или 3,4 тонны
грузов)
По методологии Кимбалла таблицы измерений связываются только с
таблицей фактов через суррогатные ключи с использованием связи «Один-коМногим». После описания таблицы фактов и таблиц измерений было
написано SQL описание для генерации таблиц и связей между ними. Это
описание представлено в приложении 1.
В
результате
выполнения
данного
SQL-описания
была
получена
следующая структура в форме «Звезда» (star-schema). Эта схема представлена
на иллюстрации 4:
28
Иллюстрация 4: Структура хранилища данных
На этом рисунке завершается этап построения структуры данных
хранилища данных. Следующим шагом в работе с хранилищем данных
является его наполнение данными, собранными на этапе поиска и
моделирования данных. По методологии построения хранилищ данных файлы
с собранной информацией являются внешними источниками по отношению к
хранилищу данных. Применение инструментария, который
обеспечит
корректное наполнение хранилища, будет рассмотрено в следующей части.
29
2. Применение ETL-инструмента.
Результатом процесса сбора и моделирования данных стали файлы в
различных форматах (.txt, .xls, .xlsx, .csv). К этим файлам относятся:

Файл
Авиакомпании.txt
–
файл,
содержащий
информацию
об
авиакомпаниях, включающую их наименования на русском и английском
языках и их web-ресурсы.

Файл Места.csv – файл со списком регионов Российской федерации с
названием федерального округа, включающего регион, и с наименованием
регионального центра.

Файл dirAndType.xls – файл, относящийся к измерениям «Тип перевозки»
и «Направление перевозки». Данные в Excel-файле разнесены по 2 листам
книги.

Файл Объемы_перевозок.xlsx – файл, в котором содержится информация
по объемам перевозок грузов с указанием года, квартала, региона,
направления перевозки, типа перевозки и компании (model_company).
Суть данного этапа заключается в корректной загрузке данных из
перечисленных выше файлов в хранилище данных с учетом того, что таблица
фактов соединяется с измерениями через суррогатные ключи измерений [24].
Также в ETL системе Pentaho Data Integration необходимо сгенерировать
временные данные и загрузить их в измерение dim_date.
Как упоминалось в 1 главе, графическая оболочка для проектирования и
проверки выполнения функций Pentaho Data Integration (PDI) именуется
Spoon. Эта программа позволяет реализовывать двухуровневый процесс
преобразования данных и передачи их в хранилище. Первый (верхний)
уровень представлен в виде Заданий (Jobs), а второй уровень состоит из
Трансформаций (Transformations). Обычно при наполнении хранилища
данных используется одно задание, состоящее из нескольких трансформаций.
Трансформации в задании выполняются последовательно [19].
30
В данной части процесс обработки данных и закачки их в хранилище
будет построен следующим образом:
(1) Создание трансформации «Генерация временного измерения»
(2) Создание трансформации «Регионы»
(3) Создание трансформации «Направления перевозки»
(4) Создание трансформации «Типы перевозки»
(5) Создание трансформации «Авиакомпании»
(6) Создание трансформации «Заполнение таблицы фактов»
(7) Создание и запуск задания «Заполнение ХД»
(8) Проверка результатов
Схема трансформации «Генерация временного измерения» представлена
на иллюстрации 5.
Иллюстрация 5: Трансформация "Генерация временного измерения"
Схема трансформации «Регионы» представлена на иллюстрации 6.
31
Иллюстрация 6: Трансформация "Регионы"
На данном изображении представлены свойства шага по загрузке данных из
файла. В поле «The row number field name» (имя поле для номера строки)
указано наименование столбца, который система будет автоматически
добавлять последовательные номера строк. Этим действием производится
генерация суррогатных ключей для таблицы измерения. То же самое действие
проделывается и с остальными таблицами измерений, так как в источниках
данных (файлах) суррогатных ключей нет.
Трансформация
«Направления
32
авиатранспортных
перевозок»
представлена на иллюстрации 7:
Иллюстрация 7: Трансформация "Направление перевозки"
Трансформация «Типы перевозки»:
Иллюстрация 8: Трансформация "Типы перевозки"
Трансформация «Авиакомпании»:
Иллюстрация 9: Трансформация "Авиакомпании"
Трансформация «Заполнение таблицы фактов» имеет более сложную
структуру. При заполнении таблицы фактов применяется техника просмотра
измерений для получения суррогатных ключей, которые будут содержаться в
таблице фактов. Трансформация представлена на иллюстрации 10.
33
Иллюстрация 10: Трансформация «Заполнение таблицы фактов»
На данном шаге производится просмотр каждого измерения для каждой
строки из файла «Объемы_перевозок.xlsx» и в соответствии и натуральным
атрибутом извлекается суррогатный ключ из просматриваемого измерения.
Эта операция выполняется при участии объектов PDI под названием
Combination Dimension lookup/update (просмотр/обновление измерения).
Cуррогатные ключи добавляются к массиву данных, и на последнем шаге из
этого массива в таблицу фактов записываются только суррогатные ключи и
меры.
34
Схема задания «Заполнение ХД» представлена на иллюстрации 11. Данный
процесс относится к полной загрузке данных в хранилище данных.
Иллюстрация 11: Задание "Заполнение хранилища данных"
После запуска задания начнется процесс последовательного выполнения
трансформаций:

процесс начинается с точки START

далее идет проверка соединения с базой данных

затем идет последовательная загрузка всех измерений

далее загружается таблица фактов

процесс заканчивается в точке SUCCESS, а также система выдает
сообщение об успешной загрузке:
35
Иллюстрация 12: Сообщение об успешной
загрузке данных в хранилище
После завершения процесса в журнале задания появились следующие записи:
Иллюстрация 13: Содержание журнала событий PDI после завершения задания
Процесс завершился успешно. Также необходимо осуществить проверку
наличия данных в самой СУБД. Для этого можно написать простой запрос [4]:
select * from dbo.fact_transportation;
В результате выполнения запроса система вернула 1624 строки. Пример
нескольких строк показан на иллюстрации 14.
36
Иллюстрация 14: Результаты выполнения запроса
Этап транспортировки данных из внешних источников в хранилище
успешно завершен. В результате получено заполненное хранилище данных, к
которому можно применять BI-инструменты. Этому будет посвящена
следующий параграф.
37
3. Применение BI-приложения и моделей data mining.
В данной части работы будет рассмотрено применение BI-инструментов
для консолидированного отображения данных [9], а также моделей Data
Mining для получения прогнозов по развитию авиатранспортной системы
России.
В первой главе был проведен обзор инструментов анализа данных. В
качестве инструмента BI была выбрана среда Microsoft Sql Server Analysis
Services (SSAS) [17]. В данной среде будет построен многомерный куб на
основе базы данных, спроектированной и заполненной на предыдущих шагах.
SSAS предоставляет разработчикам возможность создания многомерных
кубов при помощи Microsoft BI Development Studio. Создание куба в данной
среде имеет форму проекта. В проекте имеется набор объектов, как показано
на иллюстрации 15
Иллюстрация 15:
Структура проекта
На
рисунке
представлены
такие
объекты,
как
источники
данных,
представления источников данных, кубы, измерения, модели добычи данных и
прочие.
В первую очередь необходимо определить источник данных. В данном
случае необходимо организовать соединение с базой данных AirAnalysis через
драйвер Ole Db.
38
После
настройки
источника
данных
необходимо
создать
объект
представления данного источника. В свойствах этого объекта указываются
таблицы и их поля, которые будут задействованы при создании многомерного
куба. На иллюстрации 16 показана схема созданного представления:
Иллюстрация 16: Представление источника данных
На основе представления строится многомерный куб. В процессе создания
куба указывается, какая таблица будет таблицей фактов, а какие — таблицами
измерений. После создания при помощи мастера создания кубов система
генерирует схему куба, которая представлена на иллюстрации 17.
39
Иллюстрация 17: Схема многомерного куба
По сути, эта схема такая же, как и схема представления источника данных с
тем лишь отличием, что таблицы обозначаются разными цветами: желтым —
таблица фактов, синим — таблицы измерений. Описание таблиц измерений
приведено в таблице 8.
Таблица 8: Описание таблиц измерений многомерного куба
Название
таблицы
Атрибуты
Иерархии
Ключевое поле
Тип измерения
dim_date
date_id,
date_year,
date_quater,
date_date
уear - quater
date_id
Временное
измерение
dim_company
company_id,
company_title_rus,
company_title_eng,
company_web_site
нет
company_id
Обычное
(regular)
измерение
40
dim_direction
direction_id,
direction_title,
direction_desc
нет
direction_id
Обычное
(regular)
измерение
dim_place
place_id,
place_fed_distinct,
place_region,
place_center
fed_distinct region
place_id
Обычное
(regular)
измерение
dim_transportation
_type
tr_type_id,
tr_type_title,
tr_units
нет
tr_type_id
Обычное
(regular)
измерение
На этом заканчивается процесс создания многомерного куба. Далее из
него можно различными способами получать интересующую пользователя
информацию. Одним из таких способов является язык MDX [25]. Этот язык
специально предназначен для создания запросов к многомерным кубам.
В рамках исследования стоит следующий вопрос: «Увеличивалась ли доля
авиатранспортных
потоков
в
МТУ
по
отношению
к
общему
авиатранспортному потоку по стране?». На этот вопрос легко можно ответить,
используя язык MDX и MS Excel. MDX-запрос имеет следующий вид:
select {[Dim Date].[Hierarchy].[Date Year].&[2005],[Dim Date].[Hierarchy].[Date Year].&[2006],
[Dim Date].[Hierarchy].[Date Year].&[2007],[Dim Date].[Hierarchy].[Date Year].&[2008],
[Dim Date].[Hierarchy].[Date Year].&[2009],[Dim Date].[Hierarchy].[Date Year].&[2010],
[Dim Date].[Hierarchy].[Date Year].&[2011]} on Columns,
{[Dim Place].[Place Region].&[Московский регион],
[Dim Place].[Place Region].[All]
} on rows
from [Air Analysis]
Иллюстрация 18: Результат MDX-запроса
Результат выполнения запроса показан на иллюстрации 18.
В первой строке представлены ежегодные суммарные объемы авиаперевозок
для Московского региона, а во второй — для всех регионов, рассматриваемых
в исследовании.
41
Далее эти данные были скопированы в Excel, была подсчитана доля
Московского региона в общем трафике, а затем была построена диаграмма,
показывающая динамику изменения данной величины. Диаграмма изображена
на иллюстрации 19.
Иллюстрация 19: Доля МТУ 2005-2011 гг.
По графику хорошо видно, как изменяется доля МТУ за период с 2005 по 2011
год. После 2008 года доля МТУ значительно понизилась. Скорее всего, это
было вызвано экономическим кризисом. Однако доля МТУ выросла с 0,21 до
0,22 за указанный период. Это говорит о том, что авиатранспортная система
России
за
последнее
десятилетие
стала
более
централизованной
и
несбалансированной.
Следующим механизмом, при помощи которого из многомерного куба
можно получить полезные данные, - это модели data mining (добыча данных)
[9]. В SSAS есть встроенный набор моделей, таких как «Временные ряды»,
«Алгоритм
нейронной
сети»,
«Линейная
регрессия»,
«Кластеризация
последовательностей» и прочие. В данной работе поставлено две задачи,
которые можно постараться решить при помощи моделей data mining.
Во-
первых, это прогнозирование объемов авиаперевозок до определенного года (в
исследовании: до 2021 года), а, во-вторых, это выявление регионов, которые
наиболее предрасположены к развитию на их территории транспортных узлов
или «хабов». Первая задача будет решаться при помощи алгоритма временных
42
рядов, а вторая задача будет решаться с использованием алгоритма
кластеризации.
Результатом алгоритма временных рядов является график, часть которого
строится по имеющимся в хранилище данным; другая часть графика — это
прогноз. График, отражающий динамику роста авиатранспортных потоков,
полученный после использования алгоритма временных рядов, представлен
на иллюстрации 20.
Иллюстрация 20: Динамика изменения объемов авиатранспортных потоков
Прогнозные данные показаны на графике пунктиром. По рисунку видно, что
тенденция роста объема авиатранспортных потоков сохранилась. Также
видно, что с 2013 по 2017 год увеличиваются сезонные флуктуации, но к 2018
году система предсказывает значительное сглаживание таких колебаний. В
целом, модель выдает прогнозное значение на 2 квартал 2021 года, равное 120
000 тонн перевезенных грузов на территории России. Значение этого
показателя в первом квартале 2005 года равнялось чуть более 30 000 тонн. То
есть модель спрогнозировала 4-х кратный рост объемов авиатранспортных
потоков.
Алгоритм кластеризации предполагает группировку данных по кластерам.
В результате применения алгоритма является граф, где кластеры являются
43
вершинами. Задача, которую должен решить алгоритм, предполагает
выделение регионов, которые наиболее предрасположены к развитию на их
территории транспортных хабов. Схема, полученная в результате применения
модели, представлена на иллюстрации 21.
Иллюстрация 21: Кластеры, выделенные в модели
Синим цветом (причем разной насыщенности) выделены наиболее
подходящие кластеры. Далее будут выписаны регионы, содержащиеся в каждом
выделенном кластере:
Москва:
Московский регион
Хабы (1 приоритет):
Ленинградский регион, Тюменская область
Хабы (2 приоритет):
Ханты-Мансийский автономный округ (Югра)
Хабы (3 приоритет):
Краснодарский край, Республика Татарстан, Свердловская область
По полученным результатам можно сформировать список городов,
44
которые
потенциально
могут
стать
транспортными
хабами.
Список
потенциальных хабов представлен в таблице 9.
Таблица 9: Регионы, города и их числовые обозначения
Название региона
Приоритет
Название города
Номер на
карте
Ленинградский регион
1
Санкт-Петербург
1
Тюменская область
1
Тюмень
2
Ханты-Мансийский
2
Сургут
3
Краснодарский край
3
Краснодар
4
Республика Татарстан
3
Казань
5
Свердловская область
3
Екатеринбург
6
автономный округ (Югра)
Также данные города отмечены на карте России [21] номерами
соответственно таблице для большей наглядности (иллюстрация 22).
Иллюстрация 22: Карта России с указанием потенциальных хабов, сделана с использованием
сервиса Яндекс.Карты
К сожалению, система не выделила ни одного региона, находящегося на
Дальнем Востоке или в Западной Сибири.
Итак, в данной части работы было продемонстрировано применение
45
инструментов интеллектуального анализа и моделей добычи данных.
Благодаря этому были получены результаты, соответствующие задачам и
целям работы, а именно:

прогноз динамики развития авиатранспортной отрасли России

выделение
аэропортов,
которые
потенциально
могли
бы
стать
транспортными узлами в России, тем самым разгрузив московский
транспортный узел.
Несмотря на то, что данные были смоделированы, система даже смогла
распознать кризис 2008 года. Это видно по анализу изменения доли
московского региона в общем авиатранспортном трафике по стране. Поэтому
можно утверждать, что предполагаемые системой тенденции в целом
соответствуют реальности.
46
Заключение.
В проделанной работе были продемонстрированы навыки владения
основными понятиями и методами, связанными с концепцией хранилищ
данных (ETL, BI, data mining). Также было показано умение собирать данные
и моделировать данные на основе реальной информации. При анализе данных
было отмечено, что смоделированные данные в целом отражают реальные
события, произошедшие в экономике России (например, кризис 2008 года).
В работе был решен ряд задач и были найдены ответы на ряд важных
вопросов, касающихся авиатранспортной отрасли России, например:

Какую долю в общем авиатранспортном потоке по стране занимает
трафик через московский транспортный узел? Какая динамика изменения этой
доли прослеживается в период с 2005 по 2012 год?

В
каком
направлении
и
какими
темпами
будет
развиваться
авиатранспортная отрасль России в разрезе объемов авиаперевозок?

Как можно оптимизировать авиатранспортную сеть России? Какие
аэропорты необходимо развивать, чтобы разгрузить московский транспортный
узел, тем самым уменьшив степень централизации авиатранспортной системы
страны?
Результаты реализации средств интеллектуального анализа данных,
которые одновременно являются ответами на приведенные выше вопросы,
следующие:

Во вводной части работы был выполнен комплексный обзор проблемы, из
которого видно, что авиатранспортная система России представляет собой
централизованную несбалансированную структуру с центром в московском
транспортном узле. Разработанная система анализа позволяет уточнить
конкретную долю московского региона в общем объеме перевозок по стране
во временном разрезе. В третьей главе на рисунке 19 представлена динамика
47
изменения данного показателя. В среднем, в период с 2005 года по 2012 год
доля московского транспортного узла, судя по смоделированным данным,
выросла
с
20,9%
авиатранспортная
до
22,1%.
система
Этот
стала
результат
ещё
более
говорит
о
том,
централизованной
что
и
несбалансированной за указанный период.

Динамика развития авиатранспортных потоков — это очень актуальный
вопрос, которому посвящены многие коммерческие и государственные
исследования. По прогнозам можно заранее определить вектор последующего
развития отрасли. В данной работе стояла задача спрогнозировать объемы
авиаперевозок до 2020 года. Для прогнозирования объемов авиаперевозок
использовалась модель data mining, которая предсказала 4-х кратный рост
данного показателя к 2020 году относительно 2005 года.

Оптимизация авиатранспортной сети России — это очень важный вопрос,
который рассматривают как государственные органы и коммерческие
организации, так и академическая среда. Реструктуризация отрасли может в
лучшую сторону повлиять на более сбалансированное экономическое
развитие российских
регионов. Одним из вариантов реструктуризации
структуры аэропортовой сети является создание нескольких транспортных
узлов (хабов), которые будут равномерно расположены по территории всей
страны. Эти узлы помогли бы снять большую часть нагрузки с московского
транспортного узла, а также развитие этих узлов повлекло бы за собой
развитие регионов, в которых эти узлы находятся. Разработанная система
анализа с помощью алгоритма кластеризации выделила 6 регионов, которые
потенциально предрасположены к развитию на них транспортных хабов.
Результаты, полученные на этом этапе, представлены в таблице 9 и на
иллюстрации 22.
В итоге можно утверждать, что основная цель работы, а именно:
построение хранилища данных для анализа авиаперевозок на территории
России, - достигнута. Применение разработанного инструмента показало
48
корректные и адекватные результаты, по которым возможно сделать прогнозы
и
выдвинуть
некоторые
предложения
по
развитию
структуры
авиатранспортной системы России. Но, нельзя также забывать, что система
была применена к модельным данным. То есть полученные выводы содержат
только лишь верное направление. Применение инструмента к реальным
данным показало бы более точные и правдоподобные результаты, которые
могли бы реально быть использованы на практике.
Также нужно отметить, что система разработана с возможностью
дальнейшего развития функциональности. Данные могут быть рассмотрены в
двух дополнительных разрезах (что не было сделано в данной работе), а
именно: в разрезе авиакомпаний и в разрезе видов авиаперевозок
(пассажирские,
грузовые,
проанализировать
почтовые).
авиатранспортную
Это
отрасль
позволит
для
более
решения
детально
некоторых
аналитических задач, отличных от задач, решаемых в данной работе.
49
Список использованной литературы
1. Ralph Kimball (1996). The Data Warehouse Toolkit.
2. Bill Inmon (1992). Building the Data Warehouse. 1st Edition.
3. C. Кэмерон (2009). Аналитические службы СУБД Microsoft SQL Server
2008 шаг за шагом.
4. М. Грабер (1993). Понимание SQL.
5. A. S. Pulvirenti, M. C. Roldán (2011). Pentaho Data Integration 4 Cookbook
6. Диго С. М. (2008) Базы данных. Проектирование и создание. Учебнометодический комплекс, Москва: Изд. Центр ЕАОИ
7. Герасимов Н. А. (2012) Разработка диалоговой процедуры анализа
данных в системе принятия оперативных решений. В кн.: Сборник
научных трудов SWorld.Материалы международной научно-практической
конференции: Перспективные инновации в науке, образовании,
производстве и транспорте 2012 / Под общ. ред.: А. Г. Шибаев. Т. 4:
Технические науки. Вып. 2. Одесса: Куприенко С.В., С. 100 -110.
8. Герасимов Н. А. (2007) Практикум по языку SQL в среде СУБД Access.
Москва: Российская экономическая академия имени Г.В.Плеханова
9. А.А. Барсегян, М.С. Куприянов, В.В. Степаненко, И.И. Холод (2004).
Методы и модели анализа данных: OLAP и Data Mining, С-П: БХВПетербург
10.Р. Ф. Дружаева, Е. И. Меркулова (2012). Бизнес-модель развития грузовых
авиаперевозок в Российской Федерации, Наука и транспорт. Гражданская
авиация, №1, 20-22
11.М. В. Сацик (2010). «Анализ состояния и развития авиатранспортной
системы», реферат
12. А. Карпов (2011). «Некоторые аспекты региональных авиаперевозок»,
доклад на Международном Авиатранспортном Форуме в Ульяновске
13.МинТранс Рф (2012). проект «Дорожной карты»
50
14. Интернет-форум, посвященный языку SQL <www.sql.ru>
15.Сайт федеральной службы статистики <http://www.gks.ru/>
16. Сайт торговой клиринговой палаты (ТКП) <http://www.tch.ru/>
17. Сообщество разработчиков Microsoft <http://msdn.microsoft.com/>: статьи по
продуктам MS SQL Server, SS Integration Services, SS Analysis Services.
18.Официальный сайт компании Oracle <http://www.oracle.com/>
19. Сайт сообщества пользователей и разработчиков на платформе Pentaho
<http://wiki.pentaho.com/>
20.Сайт консалтинговой компании Gartner <http://www.gartner.com/>
21. Интернет-сервис Яндекс.Карты <http://maps.yandex.ru/>
22. Статья по концепции Data Vault <http://www.dwh-club.com/ru/dwh-bi-articles/vseo-data-vault.html>
23. Статья
по
концепции
EAV
<http://www.magentocommerce.com/wiki/2_-
_magento_concepts_and_architecture/magento_database_diagram>
24.Статья о применении ETL-процессов <http://www.jetinfo.ru/stati/etl-tekhnologiyasoputstvuyuschaya-lyuboj-bi-initsiative/etl>
25.Федоров А., Елманова Н. (2002). Введение в OLAP – технологии Microsoft.
М.: Диалог МИФИ.
51
Приложение 1. SQL описание для генерации таблиц для хранилища
данных.
Dim_date
create table dim_date(
date_id int primary key,
date_date datetime not null,
date_year int,
date_quater int
);
Dim_place
create table dim_place(
place_id int primary key,
place_fed_distinct varchar(50),
place_region varchar(50),
place_center varchar(50)
);
Dim_direction
create table dim_direction(
direction_id int primary key,
direction_title varchar(15),
direction_desc varchar(100)
);
Dim_transportation_type
create table dim_transportation_type(
tr_type_id int primary key,
tr_type_title varchar(30),
tr_units varchar(20)
);
Dim_company
create table dim_company(
company_id int primary key,
company_title_rus varchar(50),
company_title_eng varchar(50),
company_web_site varchar(50)
);
FactTransportation
create table fact_transportation(
trans_id int primary key,
date_id int Foreign key references dim_date(date_id),
place_id int Foreign key references dim_place(place_id),
direction_id int Foreign key references dim_direction(direction_id),
tr_type_id int Foreign key references dim_transportation_type(tr_type_id),
company_id int Foreign key references dim_company(company_id),
value real not null
);
52
Приложение 2. Инструкция по установке продукта Pentaho Data
Integration.
PDI
является
мощным
и
в
тоже
время
простым
в
использовании
многофункциональным продуктом для интеграции данных. К тому же данная система
имеет open source версию (Kettle), которая сходна по функционалу с коммерческой версией.
Функционал продукта позволяет:

переносить данные между пользовательскими приложениями;

экспортировать данные из баз данных в плоские файлы;

производить массовую загрузку данных в базу данных;

производить очистку данных;

интегрировать приложения.
PDI состоит из следующих компонентов:
1. Spoon – графический инструмент для создания и тестирования разрабатываемых
процессов (в том числе ETL);
2. Pan – инструмент, позволяющий инициализировать разработанные в Spoon
трансформации (transformations) из терминального окна;
3. Kitchen - инструмент, позволяющий инициализировать разработанные в Spoon задания
(jobs) из терминального окна;
Скачать PDI можно по ссылке:
http://sourceforge.net/projects/pentaho/files/Data%20Integration/.
После скачивания архива, необходимо распаковать его в любой каталог по выбору,
например, в каталог “C:\Program Files”.
PDI работает со средой Sun Java Runtime Environment (JRE) версии 1.5 (иногда
называемой 5.0) или более новой. Её можно загрузить с сайта www.oracle.com. Также
необходимо отметить, что перед запуском PDI нужно добавить путь к установленной JRE в
переменную среды Path. Переменные среды редактируются в панели управления по
следующему
пути:
Панель
управления\Система\Дополнительные
управления\Все
параметры
элементы
системы
->>
панели
Вкладка
«Дополнительно». На рисунке ниже показан пример заполнения данной переменной.
53
Редактирование системной переменной Path
Важно отметить, что путь к JRE добавляется в конец значения переменной.
Теперь можно запускать Spoon. Для этого необходимо открыть файл spoon.bat,
находящийся в папке PDI\data-integration.
Если запуск удался, то система готова к работе.
Дополнительные сведения и простой вводный пример по использованию PDI можно
посмотреть по ссылке http://wiki.pentaho.com/display/EAI/02.+Spoon+Introduction.
54