Описание предметной области

Жилищно-коммунальное хозяйство является одной из основных отраслей народного хозяйства Российской Федерации, охватывающей многоотраслевой производственно-технический комплекс, потребность в продукции которого практически не ограничена.

Система ЖКХ представлена жилыми, общественными зданиями, эксплуата-ционными, ремонтно-строительными, транспортными, энергетическими и другими предприятиями, составляющими сложную социально-экономическую систему, от результативности, функционирования которой зависит развитие городских объектов и состояние среды обитания жителей города.

Анализ состояния информационно-аналитического обеспечения городского ЖКХ выявил ряд проблем:

· отсутствие единого подхода к решению задач управления на основе учета взаимодействия всех управляемых процессов территории или отрасли с макро- и микропроцессами, происходящими в пределах и за пределами управляемого объекта;

· многократное дублирование однотипных данных в различных территориальных и отраслевых системах;

· отсутствие актуальной и объективной статистик о текущем состоянии сферы городского хозяйства, необходимой органам исполнительной власти для принятия наиболее эффективных управленческих решений;

· отсутствие информационной инфраструктуры для перехода к комплексному решению задач управления;

· отсутствие средств оперативного анализа и поддержки управленческих решений.

Перечисленные проблемы указывают на необходимость разработки и реализации комплексного подхода к обеспечению информационно-аналитической поддержки управления ЖКХ. Реализация такого подхода невозможна без применения технологии оперативной аналитической обработки данных (OLAP- Online Analytical Processing).

В процессе принятия решений по управлению ЖКХ лицам, принимающим решения, приходится учитывать большое количество показателей, критериев и факторов. Каждая конкретная задача по управлению ЖКХ обычно носит комплексный характер. Риски и потенциальные отрицательные последствия принятого решения могут быть достаточно велики. Практически в любых управленческих задачах существуют разного рода неопределенности, связанные с противоречивостью критериев, неполнотой знаний о проблеме, невозможностью количественного измерения тех или иных факторов и показателей. Принятие решения, как правило, представляет собой выбор из списка возможных альтернатив. Принять «правильное» решение – значит выбрать альтернативу из числа возможных, обеспечивающую с учетом всех разнообразных критериев, факторов и требований оптимизацию общей ценности, т.е. в максимальной степени способствующую достижению поставленной цели.

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

Использование информационно-аналитической поддержки на основе хранилища данных позволит перейти на новый уровень управленческих решений по оперативному управлению и планированию развития ЖКХ, основанный на консолидированных интегрированных данных по отрасли и региону в целом, повысить оперативность и качество принимаемых решений.

Постановка задачи

Впервые термин «business intelligence» (BI) был введен в обращение аналитиками Gartner в конце 1980-х годов, как «пользователецентрический процесс, который включает доступ и исследование информации, ее анализ, выработку интуиции и понимания, которые ведут к улучшенному и неформальному принятию решений». Позже в 1996 году появилось уточнение — «инструменты для анализа данных, построения отчетов и запросов могут помочь бизнес-пользователям преодолеть море данных для того, чтобы синтезировать из них значимую информацию, — сегодня эти инструменты в совокупности попадают в категорию, называемую бизнес-интеллект (BI)».

BI в широком смысле слова определяет:

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

· информационные технологии (методы и средства) сбора данных, консолидации информации и обеспечения доступа бизнес-пользователей к знаниям;

· знания о бизнесе, добытые в результате углубленного анализа детальных данных и консолидированной информации [4].

Технология традиционных СУБД была не способна в полной мере обеспечить потребности BI-систем. Поэтому с 90-х годов получает развитие технология хранилища данных (Data Warehouse).

В основе концепции хранилища данных (ХД) лежат две основные идеи – интеграция разъединенных детализированных данных в едином хранилище и разделение наборов данных и приложений, используемых для оперативной обработки и применяемых для решения задач анализа. Определение понятия «хранилище данных» первым дал Уильям Г. Инмон в своей монографии [5]. В ней он определил хранилище данных как «предметно-ориентированную, интегрированную, содержащую исторические данные, не разрушаемую совокупность данных, предназначенную для поддержки принятия управленческих решений».

Концепция, методы и средства ХД определяют подходы и обеспечивают интеграцию, очистку, ретроспективное хранение информации, предназначенной для анализа, отвечают на вопрос: «Как подготовить информацию для анализа?». Технология BI определяет методы и средства доступа и оперативного анализа информации в терминах предметной области. Средства BI не обязательно должны работать в инфраструктуре ХД, но в этом случае проблема очистки и согласования данных возлагается на них, причем осуществлять эти операции придется на лету или же предварительно, но для обособленного информационного ресурса. Кроме того, есть эффект влияния на производительность и надежность оперативной системы обработки транзакций. Вот почему хорошей корпоративной практикой является выделение транзакционной и аналитической составляющих и применение для второй различных решений по ХД [6].

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

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

Во-вторых, обычные базы данных подвержены постоянным изменениям в процессе работы пользователей, а ХД относительно стабильно: данные в нем обычно обновляются согласно расписанию (например, еженедельно, ежедневно или ежечасно — в зависимости от потребностей). В идеале процесс пополнения представляет собой просто добавление новых данных за определенный период времени без изменения прежней информации, уже находящейся в хранилище.

И, в-третьих, обычные базы данных чаще всего являются источником данных, попадающих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов [7].

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

Типовая архитектура BI-системы, использующей глобальное ХД, показана на рисунке 1.1.

Рисунок 1.1 – Архитектура BI-системы на основе глобального ХД

Данная типовая архитектура представляет собой совокупность следующих подсистем:

1. Программное обеспечение промежуточного слоя. Это слой программного обеспечения, который связывает компоненты ПО или приложения, позволяя им обмениваться данными. За счет унифицированной поддержки функций промежуточное ПО обеспечивает прозрачную работу приложений в неоднородной сетевой среде. Оно сглаживает различия аппаратно-программных платформ, дает экономию времени и средств при разработке систем [8].

2. Подсистема OLTP-источников. К ним могут относиться файлы, базы данных, ERP и CRM-источники.

3. ETL-подсистема. Данная подсистема осуществляет извлечение данных из OLTP-источников, производит их предварительную обработку, связанную с фильтрацией, очисткой и преобразованием, а также выполняет загрузку результирующих данных в ХД. Перед обработкой данные из OLTP-источников могу загружаться в специальную промежуточную область хранения (staging area). Эта область используется для временного хранения копии данных из OLTP-источников в случае, если все необходимые данные из OLTP-источников должны быть в наличии перед началом интеграции данных в ХД. В подавляющем большинстве случаев применение промежуточной области хранения не требуется, так как ETL-инструментарий способен загружать данные в ХД непосредственно из OLTP-источников.

4. Хранение данных. Данная подсистема включает в себя непосредственно хранилище данных, являющееся ядром всей BI-системы.

5. Пользовательский уровень. Предоставляет пользователям (чаще всего аналитикам), обращаясь напрямую к хранилищу данных, формировать различную отчетность, проводить OLAP и Data Mining анализ.

Задачей данного дипломного проекта является разработка подсистемы отчетов, используемой в аналитической системе жилищно-коммунальных компаний "Абонент", и информационно-методического обеспечения для нее. Внедрение данной подсистемы отчетности в систему позволит проводить централизованный анализ данных и автоматизирует составление отчетности.

Данную задачу можно разделить на следующие подзадачи:

· разработка информационно-методического обеспечения подсистемы отчетов;

· формирование иерархии подсистемы отчетов;

· разработка технологии создания шаблонов отчетов;

· разработка шаблонов отчетов.

Разрабатываемая подсистема отчетов должна удовлетворять следующим требованиям:

· реализовано на свободно-распространяемом программном обеспечении;

· поддерживает возможность анализа во временном (день, месяц, квартал, год) разрезе;

· поддерживает возможность добавления, изменения и выгрузки отчетов;

· иерархия отчетов имеет понятную структуру.

Не нашли, что искали? Воспользуйтесь поиском по сайту: