Информационно-аналитическая система

-Web-интерфейс. Получение данных через Web-страницы с доступом к любым данным хранилища, а также для выпуска отчетов через Интернет;

-Интерпретатор пользовательских интерфейсов. Он позволит пользователям создавать новые экранные формы без перекомпиляции системы;

-Пакетная генерация отчетов. Отчеты системы можно выпускать по сценарию и расписанию и рассылать потребителям в готовом виде по e-mail. Так можно обеспечивать сотрудников регулярными пакетами отчетов;

-Библиотека прикладных классов. Библиотека прикладных классов может быть объектной оболочкой над базой данных системы и предоставлять удобный и надежный доступ ко всем ее данным;

-Хранимые процедуры. Доступ к данным системы можно получить через специальный бизнес-слой - библиотеку хранимых процедур. Это позволяет разрабатывать собственные интерфейсы и аналитические приложения на произвольных языках программирования (Delphi, C++ и пр.).

Библиотека хранимых процедур может быть разработана таким образом, чтобы предоставлять доступ ко всем данным на чтение, изменение и запись. Для каждого вида объектов (счета, документы, клиенты) можно разработать специальные генерируемые аналитические процедуры, оптимизированные для создания аналитических приложений. Такие как перечисленные ниже:

-Генератор аналитических выборок. Аналитические выборки могут применяться внешними OLAP-инструментами, такими как BusinessObjects, произвольными генераторами отчетов, такими как Crystal Report, другими системами;

-Генератор регламентированных отчетов. Встроенный в систему генератор отчетов позволяет создать отчет автоматически на основе заданной аналитической выборки или при помощи визуального редактора настроить отчет произвольной формы;

-Com-интерфейс. Для доступа к данным хранилища из сред программирования типа Visual Basic можно разработать специальный COM объект, через который можно будет вызывать хранимые процедуры системы. Любое VBA-приложение (Excel, Word) или среда разработки, поддерживающая COM (MS Visual Studio, Visual Foxpro, Access) сможет использовать данные системы;

-Библиотека функций MS Excel. При установке клиентского модуля системы в Excel добавляется библиотека пользовательских функций. Эта библиотека позволяет создавать произвольные отчеты в Excel с использованием данных системы нетехническим пользователям: бухгалтерам, экономистам;

-Прямой OLAP-анализ. Для выпуска отчетов и произвольного анализа данных может быть разработан универсальный OLAP-клиент, который предоставит конечным пользователям в зависимости от их потребностей и квалификации инструменты выпуска заранее жестко сконфигурированных отчетов, выпуска заранее настроенных динамических отчетов, быстрой настройки без программирования собственных отчетов;

-Генерация микрокубов. Микрокуб содержит в себе упакованный набор данных. Он, подобно книге Excel, является универсальным контейнером аналитических приложений;

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

Режим исследования

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

Процесс исследования данных включает в себя три основных операции:

-получение среза информации;

-представление информации;

-детализация информации.

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

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

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

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

2.8 Система управления базами данных

Реляционные СУБД, ориентированные на реализацию систем операционной обработки данных, менее эффективными в задачах аналитической обработки, чем многомерные базы данных. Это связано, во-первых, с наличием достаточно жестких ограничений накладываемых существующей реализацией языка SQL (structured query language - структурированный язык запросов). Примером такого реально существующего ограничения является предположение о том, что данные в реляционной базе неупорядочены (или более точно, упорядочены случайным образом). При этом их упорядочивание требует дополнительных затрат времени на сортировку при каждом обращении к базе данных.

Во-вторых, для обеспечения приемлемого времени ответа, при использовании реляционных СУБД, необходимо уже на этапе проектирования знать обо всех возможных типах запросов, необходимых срезах и уровнях агрегации данных.

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

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

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

Использование многомерных баз данных в информационно-аналитических системах имеет нижеследующие достоинства.

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

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

С другой стороны, имеются существенные ограничения.

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

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

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

Многомерные базы, в силу чисто исторических причин, “не умеют” работать с большими объемами данных. На сегодняшний день, их реальный предел - база объемом в 10-20 гигабайт. И хотя это ограничение не связано с какими-либо внутренними объективными недостатками многомерного подхода и, скорее всего, является временным, сегодня это так. С этим нельзя не считаться.

К тому же, за счет денормализации и предварительно выполненной агрегации, 20 гигабайт в многомерной базе, в лучшем случае эквивалентны не более чем 1 гигабайту исходных данных. По оценкам Кодда, для систем основанных на многомерном представлении данных, это соотношение лежит в диапазоне от 2.5 до 100. Здесь необходимо остановиться на основном недостатке многомерных баз данных - неэффективному, по сравнению с реляционными базами данных, использованию внешней памяти.

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

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

-пожертвовать быстродействием, но это одно главных достоинств и часто одна из основных причин выбора именно многомерных СУБД;

-пожертвовать внешней памятью, но увеличение объема данных, также не увеличивает быстродействие (кроме того, многомерные СУБД в настоящее время не приспособлены для работы с большими объемами данных).

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

Следовательно, использование многомерных СУБД оправдано только при следующих условиях:

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

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

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

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

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

На решение таких задач и ориентированны многомерные СУБД. Область, где они наиболее эффективны, это хранение и обработка высоко агрегированных и стабильных во времени данных. Их применение оправдано при выполнении двух требований:

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

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

В настоящее время, многомерные СУБД всё чаще используются не только как самостоятельный программный продукт, но и как аналитические средства в хранилищах данных или традиционных оперативных системам, реализуемых средствами реляционных СУБД.

Такое решение позволяет наиболее полно реализовать и использовать достоинства каждого из подходов: компактное хранение детализированных данных и поддержка очень больших баз данных, обеспечиваемые реляционными СУБД и простота настройки и хорошие времена отклика, при работе с агрегированными данными, обеспечиваемые многомерными СУБД.

3. Создание информационно-аналитических систем (ИАС)

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

Создание информационно-аналитических систем, реально отвечающих целям и задачам организаций, представляет собой достаточно сложный процесс, включающий этапы формирования концепции, проектирования, разработки, внедрения и сопровождения. Сам характер этого процесса требует предварительной разработки достаточно жесткой фиксированной технологической схемы. Технологическая схема представляет собой в соответствии со стандартом ГОСТ Р ИСО/МЭК 12207-99, описывающим процессы жизненного цикла программных средств, последовательность работ и задач, выполняемых определенными исполнителями.

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

Технология и методика создания информационно-аналитических систем охватывает следующие виды деятельности:

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

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

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

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

4. Технология создания информационно-аналитических систем

На рисунке показана структура технологии создания информационно-аналитических систем. Технология описывает жизненный цикл информационно-аналитических систем в двух основных аспектах. По времени жизненный цикл делится на стадии, а структурно - на процессы. Процесс представляет собой некоторую последовательность работ, предназначенную для достижения определенной цели. Каждая работа в процессе состоит из выполняемых в ней задач. В различных работах могут выполняться, если это требуется, одинаковые задачи. Задача может выполняться только одной ролью. При выполнении задачи рекомендуется использовать определенные инструментальные средства. Для выполнения каждой задачи используются некоторые исходные материалы. Результатом выполнения задачи являются выходные материалы. Входные и выходные материалы также называются артефактами. Некоторые артефакты могут создаваться на основе предопределенных шаблонов.

Рисунок - Структура технологии создания и сопровождения информационно-аналитических систем

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

В технологии описаны следующие процессы: «Разработка», «Сопровождение», «Тестирование» и «Поддержка среды».

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

Процесс «Сопровождение» регламентирует работы и задачи, выполняемые персоналом, занятым в сопровождении информационно-аналитической системы во время эксплуатации.

В процессе «Тестирование» описываются работы и задачи по проведению тестирования информационно-аналитической системы на протяжении разработки, а также подготовка и проведение испытаний.

Процесс «Поддержка среды» регламентирует состав и последовательность работ и задач по обеспечению персонала разработчиков необходимой нормативно-методической документацией и комплексом инструментальных средств и их поддержки при выполнении других процессов.

5. Список использованной литературы

1. [Электронный ресурс] - режим доступа: http://iastech.org

2. Блюменау Д. И. Информация и информационный сервис. -- Л.: Наука, 1989. --190 с.

Размещено на Allbest.ru