1.1 Анализ и обработка результатов выборов в органы власти Донецкой области.

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

    Интенсивное развитие вычислительной техники позволило автоматизировать ведение учета результатов выборов в органы власти 1998, 1999 и 2000 годов, с детализацией данных вплоть до избирательного участка и его составляющих. Производится учет количества избирателей на участке, округа и района, к которым он относится, местоположения участка, предприятий и детальных данных по результатам выборов: кандидат (одномандатные избирательные округа), партии (многомандатные избирательные округа), количество проголосовавших, процент и т.д. Чаще всего для этого используются программные средства, спущенные по соответствующим ведомственным вертикалям, в которых зачастую не предусмотрены средства для проведения анализа и прогнозирования на базе имеющей информации. Во многом эти системы весьма примитивны, поэтому создаются собственные средства для хранений и многомерного анализа, что позволяет во многом не зависеть от сторонних производителей и использовать программные средства собственной разработки - как правило для решения частных проблем на уровне рабочих мест конкретных сотрудников. При этом следует отметить, что возможности горизонтального взаимообмена накопленными информационными ресурсами в интересах поддержки принятия решений на уровне области из-за несогласованного ведения ведомственных баз данных, к сожалению, никак не реализуются. 

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

    Развитие корпоративных технологий открыло перспективу автоматизации поддержки принятия решений на основе интегрированного хранилища данных, накопленных в результате функционирования систем оперативной обработки информации в рамках отдельной корпорации или региона в целом. При этом информация хранилища пополняется регулярно и располагается в хронологическом порядке. В основе поддержки принятия решений лежат три концепции: 

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

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

• поиск зависимостей в накопленной информации на основе алгоритмов интеллектуального анализа данных. 

    Используя перечисленные средства, можно решать такие задачи как мониторинг состояния управляемого объекта, проверка гипотез, анализ и прогнозирование событий, поиск зависимостей, выявление аномалий, моделирование процессов. 

1.2 Анализ средств организации хранилищ данных.

    Хранилища Данных (Data Warehouse) - это архитектура построения корпоративных информационных систем, получившая развитие вследствие желания конечных пользователей иметь непосредственный единообразный доступ к необходимым им данным, источники происхождения которых организационно и территориально распределены, а анализ которых может способствовать принятию решений. Билл Инмон, автор концепции Хранилищ Данных, определил их как "предметно ориентированные, интегрированные, неизменчивые, поддерживающие хронологию наборы данных, организованные с целью поддержки управления", призванные выступать в роли "единого и единственного источника истины", обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для оперативного анализа и принятия решений [1]. Ричард Хакаторн, другой основоположник этой концепции, писал, что цель Хранилищ Данных - обеспечить для организации "единый образ существующей реальности" [2]. 

    Такой образ реальности должен быть представлен единой информационной моделью. Проблематика моделирования данных связана с таким представлением информации, которое наиболее естественно отражает реальный мир и, в то же время, может поддерживаться компьютерными средствами. Следовательно, модель, с одной стороны, должна описывать сложную структуру данных и их взаимосвязь, а с другой - быть достаточно просто организованной, чтобы обеспечить быстрый и надежный доступ к хранимым данным. На протяжении всей истории развития информационных систем предпринимались различные попытки разрешения этого противоречия. Так на свет появились "классические" - иерархическая, сетевая и реляционная модели данных, реализованные различными СУБД. Семантические характеристики каждой из этих моделей имеют свои достоинства и недостатки, однако сегодня главенствующее положение заняла реляционная модель, поскольку ее концепция наилучшим образом формализуется традиционными механизмами математической логики. Представление данных в реляционной форме обладает достаточной гибкостью, но не обеспечивает должной интуитивности восприятия описываемых объектов с точки зрения конечного пользователя информационных систем. 

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

    Несмотря на различия в подходах и реализациях, всем хранилищам данных свойственны следующие общие черты:

    1. Предметная ориентированность. Информация в хранилище данных организована в соответствии с основными аспектами деятельности; это отличает хранилище данных от оперативной БД, где данные организованы в соответствий с процессами (выписка счетов, отгрузка товара и т п.). Предметная организация данных в хранилище способствует как значительному упрощению анализа, так и повышению скорости выполнения аналитических запросов. Выражается она, в частности, в использовании иных, чем в оперативных системах, схемах организации данных. В случае хранения данных в реляционной СУБД применяется схема "звезды" (star) или "снежинки" (snowflake). Кроме того, данные могут храниться в специальной многомерной СУБД в n-мерных кубах.

    2. Интегрированность. Исходные данные извлекаются из оперативных БД, проверяются, очищаются, приводятся к единому виду, в нужной степени агрегируются, (есть вычисляются суммарные показатели) и загружаются в хранилище. Такие интегрированные данные намного проще анализировать.

    3. Привязка ко времени. Данные в хранилище всегда напрямую связаны с определенным периодом времени. Данные, выбранные их оперативных БД, накапливаются в хранилище в виде "исторических слоев", каждый из которых относится к конкретному периоду времени. Это позволяет анализировать тенденции в развитии бизнеса.

    4. Неизменяемость. Попав в определенный "исторический слой" хранилища, данные уже никогда не будут изменены. Это также отличает хранилище от оперативной БД, в которой данные все время меняются, "дышат", и один и тот же запрос, выполненный дважды с интервалом в 10 минут, может дать разные результаты. Стабильность данных, также облегчает их анализ

    Концепция хранилищ данных предполагает не просто единый логический взгляд на данные организации, а действительную реализацию единого интегрированного источника данных. Альтернативным по отношению к этой концепции способом формирования единого взгляда на корпоративные данные является создание виртуального источника, опирающегося на распределенные базы данных различных СОД. При этом каждый запрос к такому источнику динамически транслируется в запросы к исходным базам данных, а полученные результаты на лету согласовываются, связываются, агрегируются и возвращаются к пользователю. Однако, при внешней элегантности, такой способ обладает рядом существенных недостатков. 

    1. Время обработки запросов к распределенному хранилищу значительно превышает соответствующие показатели для централизованного хранилища. Кроме того, структуры баз данных СОД, рассчитанные на интенсивное обновление одиночных записей, в высокой степени нормализованы, поэтому в аналитическом запросе к ним требуется объединение большого числа таблиц, что также приводит к снижению быстродействия.

    2. Интегрированный взгляд на распределенное корпоративное хранилище возможен только при выполнении требования постоянной связи всех источников данных в сети. Таким образом, временная недоступность хотя бы одного из источников может либо сделать работу информационно-аналитической системы (ИАС) невозможной, либо привести к ошибочным результатам. 

    3. Выполнение сложных аналитических запросов над таблицами СОД потребляет большой объем ресурсов сервера БД и приводит к снижению быстродействия СОД, что недопустимо, так как время выполнения операций в СОД часто весьма критично. 

    4. Различные СОД могут поддерживать разные форматы и кодировки данных, данные в них могут быть несогласованы. Очень часто на один и тот же вопрос может быть получено несколько вариантов ответа, что может быть связано с несинхронностью моментов обновления данных, отличиями в трактовке отдельных событий, понятий и данных, изменением семантики данных в процессе развития предметной области, ошибками при вводе, утерей фрагментов архивов и т. д. В таком случае цель - формирование единого непротиворечивого взгляда на объект управления - может не быть достигнута. 

    5. Главным же недостатком следует признать практическую невозможность обзора длительных исторических последовательностей, ибо при физическом отсутствии центрального хранилища доступны только те данные, которые на момент запроса есть в реальных БД связанных СОД. Основное назначение СОД - оперативная обработка данных, поэтому они не могут позволить себе роскошь хранить данные за длительный (более нескольких месяцев) период; по мере устаревания данные выгружаются в архив и удаляются из транзакционной БД. Что касается аналитической обработки, для нее как раз наиболее интересен взгляд на объект управления в исторической ретроспективе. 

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

    Облегченным вариантом корпоративного хранилища данных могут быть витрины данных (Data Mart), то есть тематические БД, содержащие информацию, относящуюся к отдельным аспектам деятельности организации. Концепция витрин данных была предложена Forrester Research в 1991 году [4]. При этом главная идея заключалась в том, что витрины данных содержат тематические подмножества заранее агрегированных данных, по размерам гораздо меньшие, чем общекорпоративное хранилище данных, и, следовательно, требующие менее производительной техники для поддержания. В 1994 году M. Demarest [6] предложил объединить две концепции и использовать хранилище данных в качестве единого интегрированного источника для многочисленных витрин данных. В таком варианте корпоративная информационно-аналитическая система имеет трехуровневую структуру: 

• общекорпоративное централизованное хранилище данных; 

• тематические витрины данных на уровне подразделений; 

• рабочие места конечных пользователей, снабженные аналитическим инструментарием. 

    Рассмотренная концепция ориентирована исключительно на хранение, а не на обработку корпоративных данных. Она не предопределяет архитектуру целевых аналитических систем, а только создает поле деятельности для их функционирования, концентрируясь на требованиях к данным. Таким образом, она оставляет свободу выбора во всем, что касается: 

• способов представления данных в целевом хранилище (например, реляционный, многомерный); 

• режимов анализа данных хранилища.

    Киоски и хранилища данных строятся по сходным принципам и используют практически одни и те же технологии.

    Основными компонентами хранилища данных являются следующие:

• оперативные источники данных;

• средства проектирования/разработки;

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

• СУБД;

• средства доступа и анализа данных;

• средства администрирования.

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

Выводы

    Наиболее подходящими пакетами, обладающими мощными средствами для создания ХД, многими встроенными средствами OLAP, и другими возможностями обладают Microsoft (SQL Server 2000), Hyperion (Essbase), Oracle (Oracle 9i) и Informix (DataCudes). В условиях данной задачи продукты именно этих производителей обладают средствами, максимально походящими для построения ХД. Учитывая доступность и распространенность продуктов и поддержки от корпорации Microsoft, является наиболее приемлемым использования именно архитектуры Microsoft Data Warehousing + Microsoft Analysis Services из пакета SQL Server 2000.

2. Цели и задачи исследования

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

    Перечислим основные этапы, которые необходимо пройти для достижения указанной цели: 

    1. Информационное обследование с целью разработки информационной модели хранилища данных. На основе анализа процессов, имеющих место в организации, выявляются используемые данные. При этом собирается информация о необходимых внешних данных, периодичности и форме их поступления; о внутренних системах оперативной обработки информации (источниках сведений для хранилища), их функциях и алгоритмах обработки данных. 

    2. Разработка концептуальной модели хранилища и организация ведения интегрированной базы данных. 

    3. Выбор и обоснование СУБД для хранения агрегированных данных хранилища и реляционных данных из базы выборов.

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

    5. Анализ и обоснование выбора методов и средств интеллектуальной обработки данных результатов выборов в органы власти Донецкой области.

    6. Исследование и определение оптимальной структуры моделей для анализа и прогнозирования показателей результатов выборов.

    7. Разработка специализированной информационной системы анализа накопленной информации на основе инструментальных средств поддержки принятия решений. 

3. Содержание магистерской работы

Введение
1. Анализ состояния исследуемого вопроса
1.1. Анализ состояния предметной области: использование накопленной информации о результатах выборов в органы власти
1.2. Анализ средств организации хранилищ данных
1.3. Анализ методов и средств интеллектуальной обработки данных
1.4. Цели и задачи исследования
1.5. Выводы

2. Анализ и разработка хранилища данных для хранения результатов выборов.
2.1. Анализ предметной области и выбор функциональных показателей для занесения и использования в хранилище данных.
2.2. Критерии эффективности функционирования хранилища данных.
2.3. Подбор оптимального варианта хранения данных в хранилище для заданной задачи.
2.4. Разработка структуры хранилища данных 
2.5. Выводы

3. Выбор и исследование методов интеллектуальной обработки результатов выборов.
3.1. Обоснование использования аппарата нейронной сети для прогнозирования итогов выборов.
3.2. Выбор нейропакета для построения моделей.
3.3. Определение структуры нейросетей используемой для прогнозирования итогов выборов.
3.4. Выводы.

4. Разработка информационной системы анализа и прогнозирования итогов выборов.
4.1. Разработка структуры информационной системы анализа и прогнозирования итогов выборов.
4.2. Разработка требований к техническому обеспечению системы на различных стадиях.
4.3. Разработка требований к программному обеспечению системы.
4.4. Разработка интерфейса пользователя с хранилищем данных и пакетом анализа (нейропакетом).
4.5. Выводы.

Перечень ссылок 
Приложения