Создание модели хранилища данных
Построение аналитической системы на базе многомерного хранилища данных для анализа проблем и прогнозирования развития авиатранспортной системы в России. Применение инструментов интеллектуального анализа и моделей data mining на основе хранилища данных.
Рубрика | Программирование, компьютеры и кибернетика |
Вид | дипломная работа |
Язык | русский |
Дата добавления | 07.03.2016 |
Размер файла | 1,9 M |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Размещено на http://www.allbest.ru/
Аннотация
В данной выпускной квалификационной работе проиллюстрировано построение и применение аналитической системы на базе многомерного хранилища данных для анализа проблем и прогнозирования развития авиатранспортной системы в России. В работе был осуществлен сбор данных; затем была спроектирована структура хранилища данных, в которое затем при помощи ETL-инструментов были загружены собранные данные. В конечном итоге система произвела анализ данных по авиаперевозкам, благодаря чему были сделаны некоторые выводы.
Структура работы представлена вводной частью, тремя главами по три параграфа в каждой, заключением, списком использованной литературы и двумя приложениями.
Данная работа будет интересна как специалистам, которые занимаются бизнес-аналитикой, так и другим людям интересующимся развитием и проблемами российской экономики, в частности в авиатранспортной отрасли.
Введение
Особенностью Российской Федерации является резкое различие уровня развития регионов в зависимости от их территориальной принадлежности. Регионы центральной России, такие как Москва и Московская область, наиболее развиты, в то время как уральские, дальневосточные и южные субъекты федерации обладают гораздо меньшими экономическими возможностями и в большинстве случаев развиваются (если развиваются вообще) довольно медленными темпами. Такое положение вещей накладывает свой отпечаток на производственные и коммерческие сферы деятельности, в том числе на систему и структуру авиаперевозок в России. Авиатранспортная сеть страны покрывает огромную территорию и включает в себя более 125 функционирующих аэропортов. Бульшая доля потоков в этой отрасли проходит через московский транспортный узел (МТУ), что указывает на централизованное развитие структуры транспортных маршрутов. Примерные соотношения средних исходящих грузовых потоков за месяц для десяти лидирующих по этому показателю городов России (2010-2011 гг., по данным ТКП) представлены на иллюстрации ниже [12].
По данным наглядно видно, что Москва обгоняет ближайшего преследователя (Санкт-Петербург) более чем в 10 раз. Таким образом, на базе МТУ сформировался торгово-распределительный центр для всей страны. Для такой большой страны, какой является Россия, такое несбалансированное распределение мощностей играет неблагоприятную роль и является серьезной структурной проблемой.
Очевидно, что тема развития или же реструктуризации авиатранспортной отрасли Российской Федерации заслуживает внимания. В данной работе предпринимается попытка решить проблемы, имеющие место в данной отрасли.
Основная цель работы заключается в построении хранилища данных, благодаря которому будет возможно проанализировать развитие авиаперевозок в России за некоторый период времени, спрогнозировать их объемы в будущем, а самое главное -- предложить альтернативную структуру авиатранспортной сети.
В качестве инструментария для выполнения этой задачи в работе предлагается использование технологий Data Warehousing / Business Intelligence (DWH/BI).
Данная работа предполагает следующий поток выполнения работ для достижения поставленной цели:
1. Комплексный анализ положения авиационной отрасли для выявления особенностей моделирования предметной области для исследования.
2. Формулировка конкретной задачи и формирование четкого плана выполнения работ в разрезе информационных технологий.
3. Анализ программных средств, имеющихся на рынке, для каждого из этапов реализации технологий BI/DWH, а именно: этап «проектирование хранилища данных на основе определенной СУБД (системы управления базами данных)», этап «извлечение данных из источников в хранилище данных», этап «реализация инструментов анализа и визуализации данных».
4. Создание абстрактной модели предметной области с учетом проанализированной информации на этапе комплексного анализа авиатранспортной отрасли.
5. Определение источников информации об авиационной отрасли и извлечение данных из этих источников.
6. Моделирование недостающих данных из-за их отсутствия в открытом доступе на основе других немаловажных факторов регионального развития с учетом сезонности авиаперевозок.
7. Проецирование модели предметной области на модель хранилища данных, имеющего форму «Звезда» (Star-Schema) с учетом особенностей СУБД.
8. Реализация механизма extract-transform-load (ETL) для переноса данных из различных источников в хранилище данных.
9. Применение инструментов интеллектуального анализа и моделей data mining на основе хранилища данных для получения выводов и заключений по проблеме работы.
data mining база многомерный
Глава 1. Анализ проблем авиатранспортной отрасли России
1.1 Комплексный анализ положения авиатранспортной отрасли России
Как отмечалось во вводной части данной работы, авиатранспортная сеть в России является централизованной и несбалансированной. Эта ситуация неблагоприятна для экономики как отдельных регионов, так и страны в целом.
Вопрос несовершенности авиатранспортной структуры уже поднимался неоднократно, причем доклады, исследования и предложения звучали как со стороны государственных органов, так и со стороны коммерческих организаций, являющихся участниками рынка авиаперевозок. Также интерес к проблеме проявляет академическая среда, и даже коммерческий сектор экономики, никак напрямую не увязанный с авиаперевозками. Все эти стороны рассматривают и анализируют проблему с разных точек зрения, что позволяет получить целостную картину происходящего в отрасли.
В докладе «Некоторые аспекты региональных авиаперевозок» [12] генерального директора авиакомпании «Полет» на Международном Авиатранспортном Форуме автор демонстрирует, насколько велик дисбаланс грузоперевозок между МТУ и другими регионами. Также докладчик акцентируется на односторонности потоков грузов, на очень маленьких объемах грузопотоков между отдельными регионами, на высокой конкуренции авиационного транспорта с другими видами -- автомобильным и железнодорожным. Также автор ссылается на данные по плотности населения по федеральным округам, данные по количеству складских площадей в регионах, а также на данные по входящим и исходящим грузопотокам в разных городах России. Один из выводов доклада говорит о том, что в ближайшее время не ожидается перераспределения потоков и уменьшения дисбаланса между потреблением в центральной части России (особенно в столице) и в восточных регионах.
Взгляд на проблему с точки зрения академической среды проиллюстрирован в работе «Анализ состояния и развития авиатранспортной системы (в России)» [11]. Автор работы неоднократно указывает на плачевность состояния аэродромной сети в России, приводя ряд интересных статистических данных, например «количество действующих аэропортов на территории Российской Федерации, начиная с 1991 года по настоящее время, сократилось с 1450 до 351» или «в целом износ основных фондов аэродромной сети приблизился к 80%» (касательно только региональных аэропортов). Среди выводов в работе фигурирует идея о том, что именно государство должно заниматься решением проблемы, в том числе бороться с инфраструктурной непригодностью региональных аэропортов.
На государственном уровне проблема также рассматривается, причем уже есть некоторые результаты. Министерство транспорта РФ внесло в правительство проект «дорожной карты» [13] развития региональных авиаперевозок до 2030 года, что позволило бы решить множество проблем в отрасли. В задачи проекта входит, например: финансовое обеспечение аэропортов, разработка стандарта минимальной транспортной доступности, совершенствование государственного регулирования, а также снижение стоимости региональных авиаперевозок. В целом, задачи проекта очень актуальны для отрасли. Вопрос в том, будут ли они реализованы в полной мере, и в какие сроки все это будет сделано.
Также нужно отметить статью «Бизнес-модель развития грузовых авиаперевозок в Российской Федерации» [10], авторы которой акцентируются на транспортных взаимоотношениях с другими странами. В статье говорится о потенциальных возможностях российской авиационной структуры по отношению к зарубежным перевозчикам, то есть о транзитных взаимоотношениях. Авторы пишут, что для реализации такого потенциала необходимо внедрение стандарта e-freight, а также усовершенствование (расширение) аэродромной сети, упрощение процедур приема и изменение нормативно-правовой базы по данному вопросу. Центральным аспектом является как раз расширение аэродромной сети России, другими словами -- переход от централизованной системы к распределенной: с несколькими «хабами» для более эффективной работы сети.
Из всей приведенной выше информации можно сделать вывод о том, что на сегодняшний день аэропортная сеть в России представляет собой централизованную структуру с серединой в московском транспортном узле, в то время как региональные аэропорты и аэродромы в большинстве случаев характеризуются неразвитостью, отсутствием надлежащей инфраструктуры и чрезвычайно сильным износов оборудования. Также нужно отметить, что больше половины транспортных потоков по воздуху проходят через МТУ, причем товарные потоки между регионами несоизмеримо малы. Если учитывать территориальную обширность России, то такая несбалансированная ситуация в отрасли недопустима. Абстрактно ситуация может быть представлена, как показано на иллюстрации ниже.
1.2 Формулировка основных задач работы
В данной работе лишь предпринимается попытка проанализировать авиатранспортную отрасль России в разрезе авиатранспортных потоков при помощи изученных инструментов анализа данных, относящихся к концепции Business Intelligence.
К сожалению, очень малая доля информации относительно авиатранспортных потоков находится в открытом доступе, особенно в разрезе временной динамики и в разрезе территориальной принадлежности. Поэтому, разрабатываемая система будет реализована на смоделированных данных, основанных на реальных экономических показателях. Сбору и моделированию данных в данной работе будет посвящена отдельная часть.
Из комплексного анализа проблемы следует то, что в первую очередь необходимо сфокусироваться на определении доли московского транспортного узла в общем объеме авиатранспортных перевозок по России. Первая важная задача в работе -- это определение этой доли и динамики её изменения за определенный период времени.
Также было бы интересно узнать, какая динамика развития отрасли будет наблюдаться в будущем. Из этого вытекает вторая важная задача работы -- прогнозирование объемов авиатранспортных потоков в будущем.
Немаловажно также сделать попытку предложить вариант решения проблемы несбалансированности авиатранспортной системы в России. Решение этой проблемы является третьей важной задачей работы.
Как было отмечено выше, попытка решения всех важных задач работы должна быть реализована при помощи инструментов анализа данных, существующих на сегодняшний день на рынке IT-решений.
1.3 Анализ инструментария для достижения цели работы
Так как в цели работы входит построение хранилища данных для анализа авиатранспортной системы России, то в первую очередь необходимо произвести обследование рынка компонентов хранилищ данных для более эффективной и удобной работы в процессе исследования.
Концепция BI/DWH, которая будет применяться в работе, предполагает наличие нескольких компонентов:
· Внешние источники данных. В качестве внешних источников в работе будут выступать файлы различных форматов, содержащие в себе собранную и смоделированную информацию по авиатранспортной отрасли России.
· ETL-инструмент, который поддерживает процедуры извлечения данных из внешних источников, их преобразования и дальнейшей загрузки в хранилище данных.
· Хранилище данных, в которое производится загрузка данных из внешних источников при помощи ETL процедур. Хранилище представляет собой предметно-ориентированную информационную базу данных, специально разработанную и предназначенную для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Хранилище данных реализуется в системе управления базами данных (СУБД).
· Инструменты интеллектуального анализа. Они обеспечивают анализ данных, хранящихся в хранилище данных. Основная цель интеллектуального анализа данных состоит в обеспечении необходимой информацией того круга лиц, которому эта информация необходима для принятия важных управленческих решений или для решения других важных задач. Информация может быть представлена в форме отчетов, информационных панелей, визуализированных данных и т. д.
Обобщенная схема концепции представлена на иллюстрации 3:
В данном параграфе будет сделан обзор инструментов по 3 направлениям:
· ETL;
· СУБД;
· Инструменты анализа.
На рынке существует большое количество как платных, так и бесплатных ETL-инструментов и инструментов интеграции данных. Ниже будут рассмотрены 3 решения: Microsoft SQL Server Integration Services (MSSIS), Oracle Warehouse Builder (OWB) и Pentaho Data Integration (PDI).
OWB [18] входит в семейство продуктов Oracle Developer Suite и представляет собой интегрированную CASE-среду, предназначенную для разработки и развертывания хранилищ и витрин данных. Средствами этого продукта можно проектировать, создавать и администрировать хранилища и витрины данных, разрабатывать и генерировать процедуры извлечения, преобразования и загрузки данных из различных источников, управлять метаданными. Плюсы: наглядность проектирования, стандартизованность, мультиплатформенность, управляемость компонентами хранилища данных, многофункциональность. Минусы: сложность при установке системы, возможна несовместимость с некоторыми программами, высокие системные требования.
Службы Integration Services [17] представляют собой платформу для построения высокопроизводительных решений интеграции данных и решений потока операций, включая операции извлечения, преобразования и загрузки (ETL) для хранилищ данных. Плюсы: большой объем документации, поддержка продукта, относительно небольшая цена, визуальные средства разработки. Минусы: возможна сложность в организации логики ETL процесса, продукт ориентирован только на одну.
PDI - это компонент комплекса Pentaho [19] отвечающий за процессы Извлечения, Преобразования и Загрузки данных в целевую систему (ETL). Несмотря на то, что использовать системы ETL предполагается в рамках комплекса хранения данных, средства PDI могут быть применены и для других целей: обмена данными между приложениями или базами данных, экспорта данных из таблиц баз данных в файлы, загрузки массивов данных в базы данных, обработки данных, интеграции в приложения. Плюсы: бесплатная система, понятный графический интерфейс (именуемый Spoon), многофункциональность, мультиплатформенность, легкость в инсталляции. Минусы: в системе есть недостатки, связанные с тем, что продукт является open source.
В данной работе будет использоваться инструмент Pentaho Data Integration, т. к. он является бесплатным и наиболее понятным в использовании. К тому же в отличие от SSIS в PDI имеются возможности предварительного просмотра объектов в источнике данных, прогона трансформаций в тестовом режиме, а также вывода системных уведомлений. К тому же SSIS не располагает такими возможностями как PDI при извлечении информации из файлов различных типов. Функционал этого продукта достаточен для реализации задач, поставленных в работе.
При выборе СУБД рассматривались 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.
Глава 2. Сбор данных для разрабатываемой системы
2.1 Определение модели предметной области
В данной части работы предполагается создание абстрактной модели предметной области с учетом проанализированной информации на этапе комплексного анализа авиатранспортной отрасли.
Как отмечалось ранее, авиатранспортная сеть России представляет собой несбалансированную структуру с центром в МТУ. Также отмечалось, что наблюдается тенденция ежегодного увеличения доли МТУ в общем авиатранспортном трафике по России. Из всего этого следует, что разрабатываемый комплекс должен учитывать изменения объемов авиатранспортных потоков, как минимум, в разрезах «территориальная принадлежность» и «время». Таким образом, можно абстрагироваться от описания конкретных аэропортов, а взять Регион за базовую единицу разреза «территориальная принадлежность», например, Омская область. Из анализа данных по регионам будет нагляднее понятно, какие территории претендуют на развитие в крупных городах «распределительных узлов» или, другими словами, «хабов». Родительским элементом для объекта «Регион» является «Федеральный округ», который включает в себя несколько регионов. Также у каждого региона есть свой региональный центр.
Отчетность по объемам перевозок происходит поквартально. Это тоже важно учитывать при проектировании хранилища данных в будущем.
Ключевым объектом в предметной области является «Авиаперевозки для региона», который, в свою очередь, подразделяется на Входящий поток и Исходящий поток. Каждый экземпляр этого абстрактного объекта имеет территориальную принадлежность и временную отметку, объем перевозки. Также не стоит забывать о таком понятии, как Авиакомпания. В проектируемой предметной области оно есть. Также стоит разделять перевозки на Пассажирские, Грузовые и Перевозки почты.
По данному описанию в предметной области можно выделить следующие сущности:
1. Авиаперевозки для региона (с типом перевозки, временной отметкой и направлением авиационного потока)
2. Федеральный округ
3. Регион
4. Авиакомпания
В таблице 1 представлены сущности и их атрибуты:
Таблица 1: Описание сущностей и их признаков
Имя сущности |
Признаки |
|
Авиаперевозка |
Дата, тип перевозки, направление (вход/выход), регион, авиакомпания, объем перевозки |
|
Авиакомпания |
Название, другие особенности |
|
Федеральный округ |
Наименование, федеральный центр |
|
Регион |
Принадлежность к федеральному округу, наименование, региональный центр |
В таблице ниже представлены отношения сущностей:
Таблица 2: Описание отношений между сущностями
Сущность №1 |
отношение |
действие |
Сущность №2 |
|
Федеральный округ |
1 : M |
Включает в себя |
Регионы |
|
Авиакомпании |
М : М |
Совершают рейсы по различным |
Регионам |
|
Авиакомпания |
1 : М |
Имеет много |
Авиаперевозок |
|
Авиаперевозки |
М : 1 |
Принадлежат к определенному |
Региону |
В разрабатываемой системе не ставится задача рассмотреть авиаперевозки в разрезе авиакомпаний. Но такая сущность вносится в систему для возможного дальнейшего развития проектируемого аналитического программного комплекса.
Также необходимо отметить, что в системе фигурируют только Грузовые авиаперевозки.
Разделение на виды перевозок также вводится в систему с перспективой на дальнейшее развитие.
2.2 Поиск данных в различных источниках
Коллекционирование данных является основой любого исследования. В данном исследовании необходима информация, в первую очередь, об объемах входящих и исходящих авиаперевозок в регионах России за 2005-2011 годы. Эта информация не доступна в открытых источниках, следовательно, эти данные будут смоделированы на основе других показателей развития в регионах России. В качестве таких показателей были взяты:
1. численность населения;
2. валовый региональный продукт (ВРП);
3. уровень экономической активности населения.
Эти данные были собраны для 32 крупнейших городов из 29 различных регионов за период с 2005 по 2011 год. Ниже представлен перечень регионов, по которым собирались данные:
Таблица 3: Рассматриваемые в системе регионы
Московский регион* |
свердловская область |
|
Ленинградский регион* |
ханты-мансийский а. округ (Югра) |
|
хабаровский край |
тюменская область |
|
приморский край |
республика Дагестан |
|
красноярский край |
ростовская область |
|
ярославская область |
ивановская область |
|
новосибирская область |
алтайский край |
|
иркутская область |
пермский край |
|
камчатский край |
самарская область |
|
сахалинская область |
республика Башкортостан |
|
краснодарский край |
нижегородская область |
|
республика Саха (Якутия) |
республика Татарстан |
|
магаданская область |
омская область |
|
челябинская область |
||
волгоградская область |
||
воронежская область |
* Примечание. Московский регион объединяет в себе федеральные субъекты «Москва» и «Московская область». Аналогично и с ленинградским регионом
Также важно отметить, что некоторые значения коэффициентов и параметров, введенные в данной главе, не являются результатом применения математических моделей. Они предлагаются исходя из разумных предположений. Данное допущение возможно, т. к. в работе предполагается построение системы анализа авиаперевозок, которая в свою очередь не нуждается в высокой достоверности данных, потому что является всего лишь инструментом исследования.
Регионы отбирались по следующему принципу: во-первых, были взяты регионы, на территории которых есть города-миллионники. Во-вторых, брались регионы с максимальным исходящим авиационным грузопотоком в 2011 году по статистике Торговой Клиринговой Палаты (ТКП).
Для каждого из вышеперечисленных регионов были найдены различные экономические показатели за период с 2005 по 2011 год. Чтобы как-то диверсифицировать данные показатели по значимости, были предположено, что каждому показателю соответствует определенный коэффициент. Сумма коэффициентов получается равной единице. Данные коэффициенты не рассчитывались при помощи математических или экономических моделей; они были предложены автором работы из соображений здравого смысла.
Во-первых, была собрана статистика по численности населения за указанный период. Источником послужили базы Федеральной службы государственной статистики (www.gks.ru) [15]. Численность населения -- это важнейший показатель экономического развития страны. Поэтому данному фактору присвоен коэффициент значимости 0,4 из 1.
Примечание. Коэффициенты значимости будут использоваться при моделировании данных.
Вторым, не менее важным показателем развития в регионах, данные по которому были собраны в рамках исследования, это региональный валовый продукт. Валовой региональный продукт представляет сумму валовой добавленной стоимости, созданной всеми институциональными единицами-резидентами на экономической территории региона (без учёта чистых налогов на продукты). Уровень значимости для исследования -- 0,4 из 1. Источник -- www.gks.ru [15].
Третья величина, от которой в некоторой степени зависит развитие региона, - это уровень экономической активности населения. Этот показатель представляет собой процент активного населения от общей численности региона. Например, в 2011 году в Московском регионе этот показатель составил 72,2. Значимость этого показателя не так велика, как значимость предыдущих двух показателей. Поэтому коэффициент значимости был взят равным 0,2 из 1. Источник -- www.gks.ru. [15]
Также была собрана информация о суммарном внутреннем авиатранспортном грузовом обороте за 2005-2011 годы. Источник -- ТКП [16]. В таблице 4 представлены собранные по этому пункту данные:
Таблица 4: Ежегодный объем авиатранспортных потоков в России
2005 |
2006 |
2007 |
2008 |
2009 |
2010 |
2011 |
||
197,19 |
202,94 |
231,67 |
245,08 |
224,01 |
291,02 |
306,34 |
тыс. тонн |
Дополнительно были введены коэффициенты оттока и притока грузов для каждого региона. Они нужны для того, чтобы при моделировании распределить общий грузооборот в регионе на исходящие и входящие грузопотоки. Например, если в регионе за 2005 год общий оборот грузов равняется 10 тыс. тонн, а коэффициент оттока товаров равняется 60%, то исходящий грузопоток получается равным 6 тыс. тонн, а входящий -- 4 тыс. тонн. Эта величина введена на основе приблизительных предположений, и, так как в исследовании не важна высокая точность и правдоподобность данных, её использование вполне оправдано для получения нужной информации.
Помимо данных, которые необходимы для формирования объемов авиатранспортных потоков, была собрана контекстная информация, которая будет отражена в разрабатываемой системе. В таблице ниже приведен перечень блоков собранных данных с указанием файлов, в которые эти данные были сохранены.
Таблица 5: Соответствие блоков данных файлам
Наименование блока данных |
Имя файла |
|
Перечень регионов с указанием регионального центра и федерального округа |
Места.csv |
|
Виды авиатранспортных перевозок |
DirAndType.xls |
|
Направления авиатранспортных перевозок |
DirAndType.xls |
|
Перечень авиакомпаний |
Авиакомпании.txt |
Особенности использования перечисленной информации будут отражены в последующих главах.
Следующим этапом работы является моделирование необходимых для исследования данных на базе собранных реальных показателей. Смоделированные данные будут записаны в файл Объемы_перевозок.xlsx.
1. Моделирование данных для разрабатываемой системы
Этот этап полностью посвящен моделированию данных о поквартальном объеме входящего и исходящего авиатранспортного грузопотока для 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) Вычисление объемов грузопотоков. Этот этап основан на созданной на предыдущем этапе таблице основных коэффициентов, а также на коэффициентах оттока и притока грузов и на значениях общего внутреннего авиатранспортного грузооборота. Расчёт производился по следующей формуле:
грузооборот(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.
Глава 3. Проектирование хранилища данных и инструментов анализа данных
3.1 Создание модели хранилища данных
Модель хранилища данных будет создаваться на основе описания предметной области, сделанного во 2 главе.
Хранилища данных (Data Warehouse) представляют собой специализированные базы данных, предназначенные для хранения данных, которые редко меняются, но на основе которых часто требуется выполнение сложных запросов [2]. Обычно они ориентированы на выполнение аналитических запросов, которые обеспечивают поддержку принятия решений для руководителей и менеджеров. Хранилища данных позволяют разгрузить промышленные базы данных, и тем самым позволяют пользователям более эффективно и быстро извлекать необходимую информацию. Как правило, хранилища данных оперируют с огромными объемами информации, что предъявляет к их проектированию и реализации повышенные требования.
Существует 4 наиболее распространенных методологии проектирования хранилища данных:
1. Хранилище данных в 3-НФ (третья нормальная форма) [2]. Структура представлена в третьей нормальной форме, что значительно снижает скорость ответа серверов при обработке больших объемов данных. Концепция была предложена американским ученым в сфере ИТ Биллом Инмоном в 1992 году. По утверждению Б. Инмона хранилище данных должно проектироваться с использованием нормализованной модели. К основным недостаткам реляционной модели относятся: (1) сложность для пользователей получить целостную информацию о бизнес объектах, (2) низкая производительность при больших объемах данных.
2. Многомерный (Dimensional) подход, предложенный Ральфом Кимбаллом в 1996 году [1]. Данная методология является самой распространенной на сегодняшний день благодаря своей простоте, понятности для пользователей, производительности. По Кимбаллу хранилище данных представляет собой денормализованную структуру с таблицей фактов и таблицами измерений. Факты содержат в себе меры (например, доход, количество, процент) и суррогатные ключи измерений. Измерения являются контекстной информацией (например, измерение «Клиент», «Магазин») для описания определенного факта. Однако, возможно возникновение трудностей при загрузке данных из внешних источников в хранилище в контексте интеграции данных в таблице фактов и таблицах измерений.
3. Data Vault [22]. Эта методология предполагает наличие трех видов сущностей в хранилище: узел (hub), спутник (satellite) и link (связь). Узлы содержат в себе лишь суррогатные ключи, бизнес ключи и информацию о дате загрузки объекта и об источнике. Все свойства и атрибуты хаба хранятся в спутниках. Связи отражают взаимоотношения бизнес объектов, описанных в хабах; они также могут иметь свои спутники. Примеры хаба: Клиент, Поставщик; примеры спутника: адрес клиента, имя клиента. Примеры связи: заказ, покупка, поставка. Система, спроектированная по этой методологии, характеризуется высокой степенью гибкости и масштабируемостью. Также методология обеспечивает долгосрочное хранение истории о загрузках объектов и об источниках. Авторы методологии утверждают, что Data Vault является чем-то средним между проектированием хранилищ данных в 3 нормальной форме (3NF) и проектированием хранилищ данных в форме «Звезды» (Dimensional). Однако структура Data Vault в некоторых случаях может оказаться чрезмерно сложной для предприятия, а также могут возникать проблемы во время применения аналитических инструментов из-за слишком большого количества таблиц.
4. Entity-Attribute-Value (EAV) или Сущность-Атрибут-Значение [23] это методология, основанная на описании сущностей с большим количеством потенциальных свойств (атрибутов), из которых используется лишь некоторая часть. 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 -- абстракция «регион»
Поля:
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, company-model-site.com). Данное измерение введено для потенциального совершенствования системы в будущем)
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:
На этом рисунке завершается этап построения структуры данных хранилища данных. Следующим шагом в работе с хранилищем данных является его наполнение данными, собранными на этапе поиска и моделирования данных. По методологии построения хранилищ данных файлы с собранной информацией являются внешними источниками по отношению к хранилищу данных. Применение инструментария, который обеспечит корректное наполнение хранилища, будет рассмотрено в следующей части.
3.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].
В данной части процесс обработки данных и закачки их в хранилище будет построен следующим образом:
(1) Создание трансформации «Генерация временного измерения»
(2) Создание трансформации «Регионы»
(3) Создание трансформации «Направления перевозки»
(4) Создание трансформации «Типы перевозки»
(5) Создание трансформации «Авиакомпании»
(6) Создание трансформации «Заполнение таблицы фактов»
(7) Создание и запуск задания «Заполнение ХД»
(8) Проверка результатов
Схема трансформации «Генерация временного измерения» представлена на иллюстрации 5.
Размещено на http://www.allbest.ru/
Схема трансформации «Регионы» представлена на иллюстрации 6.
На данном изображении представлены свойства шага по загрузке данных из файла. В поле «The row number field name» (имя поле для номера строки) указано наименование столбца, который система будет автоматически добавлять последовательные номера строк. Этим действием производится генерация суррогатных ключей для таблицы измерения. То же самое действие проделывается и с остальными таблицами измерений, так как в источниках данных (файлах) суррогатных ключей нет.
Трансформация «Направления авиатранспортных перевозок» представлена на иллюстрации 7:
Размещено на http://www.allbest.ru/
Трансформация «Типы перевозки»:
Размещено на http://www.allbest.ru/
Трансформация «Авиакомпании»:
Размещено на http://www.allbest.ru/
Трансформация «Заполнение таблицы фактов» имеет более сложную структуру. При заполнении таблицы фактов применяется техника просмотра измерений для получения суррогатных ключей, которые будут содержаться в таблице фактов. Трансформация представлена на иллюстрации 10.
Размещено на http://www.allbest.ru/
На данном шаге производится просмотр каждого измерения для каждой строки из файла «Объемы_перевозок.xlsx» и в соответствии и натуральным атрибутом извлекается суррогатный ключ из просматриваемого измерения. Эта операция выполняется при участии объектов PDI под названием Combination Dimension lookup/update (просмотр/обновление измерения). Cуррогатные ключи добавляются к массиву данных, и на последнем шаге из этого массива в таблицу фактов записываются только суррогатные ключи и меры.
Схема задания «Заполнение ХД» представлена на иллюстрации 11. Данный процесс относится к полной загрузке данных в хранилище данных.
Размещено на http://www.allbest.ru/
После запуска задания начнется процесс последовательного выполнения трансформаций:
· процесс начинается с точки START
· далее идет проверка соединения с базой данных
· затем идет последовательная загрузка всех измерений
· далее загружается таблица фактов
· процесс заканчивается в точке SUCCESS, а также система выдает сообщение об успешной загрузке:
Размещено на http://www.allbest.ru/
После завершения процесса в журнале задания появились следующие записи:
Размещено на http://www.allbest.ru/
Процесс завершился успешно. Также необходимо осуществить проверку наличия данных в самой СУБД. Для этого можно написать простой запрос [4]:
select * from dbo.fact_transportation;
В результате выполнения запроса система вернула 1624 строки. Пример нескольких строк показан на иллюстрации 14.
Размещено на http://www.allbest.ru/
Этап транспортировки данных из внешних источников в хранилище успешно завершен. В результате получено заполненное хранилище данных, к которому можно применять BI-инструменты. Этому будет посвящена следующий параграф.
1. Применение BI-приложения и моделей data mining.
В данной части работы будет рассмотрено применение BI-инструментов для консолидированного отображения данных [9], а также моделей Data Mining для получения прогнозов по развитию авиатранспортной системы России.
В первой главе был проведен обзор инструментов анализа данных. В качестве инструмента BI была выбрана среда Microsoft Sql Server Analysis Services (SSAS) [17]. В данной среде будет построен многомерный куб на основе базы данных, спроектированной и заполненной на предыдущих шагах.
SSAS предоставляет разработчикам возможность создания многомерных кубов при помощи Microsoft BI Development Studio. Создание куба в данной среде имеет форму проекта. В проекте имеется набор объектов, как показано на иллюстрации 15
Размещено на http://www.allbest.ru/
На рисунке представлены такие объекты, как источники данных, представления источников данных, кубы, измерения, модели добычи данных и прочие.
В первую очередь необходимо определить источник данных. В данном случае необходимо организовать соединение с базой данных AirAnalysis через драйвер Ole Db.
После настройки источника данных необходимо создать объект представления данного источника. В свойствах этого объекта указываются таблицы и их поля, которые будут задействованы при создании многомерного куба. На иллюстрации 16 показана схема созданного представления:
Размещено на http://www.allbest.ru/
На основе представления строится многомерный куб. В процессе создания куба указывается, какая таблица будет таблицей фактов, а какие -- таблицами измерений. После создания при помощи мастера создания кубов система генерирует схему куба, которая представлена на иллюстрации 17.
Размещено на http://www.allbest.ru/
По сути, эта схема такая же, как и схема представления источника данных с тем лишь отличием, что таблицы обозначаются разными цветами: желтым -- таблица фактов, синим -- таблицы измерений. Описание таблиц измерений приведено в таблице 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) измерение |
|
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.
Размещено на http://www.allbest.ru/
В первой строке представлены ежегодные суммарные объемы авиаперевозок для Московского региона, а во второй -- для всех регионов, рассматриваемых в исследовании.
Далее эти данные были скопированы в Excel, была подсчитана доля Московского региона в общем трафике, а затем была построена диаграмма, показывающая динамику изменения данной величины. Диаграмма изображена на иллюстрации 19.
Размещено на http://www.allbest.ru/
По графику хорошо видно, как изменяется доля МТУ за период с 2005 по 2011 год. После 2008 года доля МТУ значительно понизилась. Скорее всего, это было вызвано экономическим кризисом. Однако доля МТУ выросла с 0,21 до 0,22 за указанный период. Это говорит о том, что авиатранспортная система России за последнее десятилетие стала более централизованной и несбалансированной.
Следующим механизмом, при помощи которого из многомерного куба можно получить полезные данные, - это модели data mining (добыча данных) [9]. В SSAS есть встроенный набор моделей, таких как «Временные ряды», «Алгоритм нейронной сети», «Линейная регрессия», «Кластеризация последовательностей» и прочие. В данной работе поставлено две задачи, которые можно постараться решить при помощи моделей data mining. Во-первых, это прогнозирование объемов авиаперевозок до определенного года (в исследовании: до 2021 года), а, во-вторых, это выявление регионов, которые наиболее предрасположены к развитию на их территории транспортных узлов или «хабов». Первая задача будет решаться при помощи алгоритма временных рядов, а вторая задача будет решаться с использованием алгоритма кластеризации.
Результатом алгоритма временных рядов является график, часть которого строится по имеющимся в хранилище данным; другая часть графика -- это прогноз. График, отражающий динамику роста авиатранспортных потоков, полученный после использования алгоритма временных рядов, представлен на иллюстрации 20.
Прогнозные данные показаны на графике пунктиром. По рисунку видно, что тенденция роста объема авиатранспортных потоков сохранилась. Также видно, что с 2013 по 2017 год увеличиваются сезонные флуктуации, но к 2018 году система предсказывает значительное сглаживание таких колебаний. В целом, модель выдает прогнозное значение на 2 квартал 2021 года, равное 120 000 тонн перевезенных грузов на территории России. Значение этого показателя в первом квартале 2005 года равнялось чуть более 30 000 тонн. То есть модель спрогнозировала 4-х кратный рост объемов авиатранспортных потоков.
Алгоритм кластеризации предполагает группировку данных по кластерам. В результате применения алгоритма является граф, где кластеры являются вершинами. Задача, которую должен решить алгоритм, предполагает выделение регионов, которые наиболее предрасположены к развитию на их территории транспортных хабов. Схема, полученная в результате применения модели, представлена на иллюстрации 21.
Синим цветом (причем разной насыщенности) выделены наиболее подходящие кластеры. Далее будут выписаны регионы, содержащиеся в каждом выделенном кластере:
Москва:
Московский регион
Хабы (1 приоритет):
Ленинградский регион, Тюменская область
Хабы (2 приоритет):
Ханты-Мансийский автономный округ (Югра)
Хабы (3 приоритет):
Краснодарский край, Республика Татарстан, Свердловская область
По полученным результатам можно сформировать список городов, которые потенциально могут стать транспортными хабами. Список потенциальных хабов представлен в таблице 9.
Таблица 9: Регионы, города и их числовые обозначения
Название региона |
Приоритет |
Название города |
Номер на карте |
|
Ленинградский регион |
1 |
Санкт-Петербург |
1 |
|
Тюменская область |
1 |
Тюмень |
2 |
|
Ханты-Мансийский автономный округ (Югра) |
2 |
Сургут |
3 |
|
Краснодарский край |
3 |
Краснодар |
4 |
|
Республика Татарстан |
3 |
Казань |
5 |
|
Свердловская область |
3 |
Екатеринбург |
6 |
Также данные города отмечены на карте России [21] номерами соответственно таблице для большей наглядности (иллюстрация 22).
К сожалению, система не выделила ни одного региона, находящегося на Дальнем Востоке или в Западной Сибири.
Итак, в данной части работы было продемонстрировано применение инструментов интеллектуального анализа и моделей добычи данных. Благодаря этому были получены результаты, соответствующие задачам и целям работы, а именно:
· прогноз динамики развития авиатранспортной отрасли России
· выделение аэропортов, которые потенциально могли бы стать транспортными узлами в России, тем самым разгрузив московский транспортный узел.
Несмотря на то, что данные были смоделированы, система даже смогла распознать кризис 2008 года. Это видно по анализу изменения доли московского региона в общем авиатранспортном трафике по стране. Поэтому можно утверждать, что предполагаемые системой тенденции в целом соответствуют реальности.
Подобные документы
Построение схемы хранилища данных торгового предприятия. Описания схем отношений хранилища. Отображение информации о товаре. Создание OLAP-куба для дальнейшего анализа информации. Разработка запросов, позволяющих оценить эффективность работы супермаркета.
контрольная работа [1,9 M], добавлен 19.12.2015Методы построения хранилища данных на основе информационной системы реального коммерческого предприятия. Основные аналитические задачи, для решения которых планируется внедрение хранилищ данных. Загрузка процессоров на серверах. Схемы хранения данных.
контрольная работа [401,0 K], добавлен 31.05.2013OLAP как автоматизированные технологии сложного (многомерного) анализа данных, Data mining - извлечение данных, интеллектуальный анализ. Виды запросов к многомерной базе данных, их содержание и анализ полученных результатов. Схема "звезда", "снежинка".
презентация [132,1 K], добавлен 19.08.2013Архитектура и технология функционирования системы. Извлечение, преобразование и загрузка данных. Oracle Database для реализации хранилища данных. Создание структуры хранилища. Механизм работы системы с точки зрения пользователя и с точки зрения платформы.
курсовая работа [2,2 M], добавлен 22.02.2013Основы для проведения кластеризации. Использование Data Mining как способа "обнаружения знаний в базах данных". Выбор алгоритмов кластеризации. Получение данных из хранилища базы данных дистанционного практикума. Кластеризация студентов и задач.
курсовая работа [728,4 K], добавлен 10.07.2017Разработка программного обеспечения для анализа полученных из хранилища данных. Система SAS Enterprise Miner и система Weka. Расчёт капитальных затрат на создание ПМК для анализа полученных из хранилища данных с использованием библиотеки XELOPES.
дипломная работа [1,4 M], добавлен 07.06.2012Перспективные направления анализа данных: анализ текстовой информации, интеллектуальный анализ данных. Анализ структурированной информации, хранящейся в базах данных. Процесс анализа текстовых документов. Особенности предварительной обработки данных.
реферат [443,2 K], добавлен 13.02.2014Файловая организация баз данных. Взаимодействие администратора баз данных с пользователями. Иерархическая и сетевая даталогические модели системы управления базами данных. Принципиальная организация системы обработки информации на основе БД-технологии.
реферат [762,0 K], добавлен 23.12.2015Понятие и структура хранилища данных, его составные элементы и назначение. Технологии управления информацией. Методика создания базы данных и составления ее схемы, пользовательские формы, структура и содержание таблиц. Программная реализация базы данных.
дипломная работа [1,4 M], добавлен 13.04.2010Совершенствование технологий записи и хранения данных. Специфика современных требований к переработке информационных данных. Концепция шаблонов, отражающих фрагменты многоаспектных взаимоотношений в данных в основе современной технологии Data Mining.
контрольная работа [565,6 K], добавлен 02.09.2010