Автоматизированные системы обработки данных системы поддержки принятия решений

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

     В состав хранилища данных, как правило, входит:

     - виртуальное хранилище данных;

     - витрины данных;

     - глобальное хранилище данных;

     - многоуровневая архитектура хранилища данных.

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

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

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

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

     На  втором уровне поддерживаются витрины  данных на основе многомерной системы  управления базами данных (примером такой системы является Oracle Express Server). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной базы данных составляет 10-40 Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Необходимо заметить, что витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на хранилище данных и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной базы данных.

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

     Хранилища данных обладают рядом свойств:

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

     2. Интегрированность данных. Данные  в информационное хранилище поступают  из различных источников, где  они могут иметь разные имена, атрибуты, единицы измерения и способы кодировки. После загрузки в ХД данные очищаются от индивидуальных признаков. С этого момента они представляются пользователю в виде единого информационного пространства.

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

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

     5. Интеграция. Различные ОБД разрабатываются  различными коллективами разработчиков, зачастую в разное время и различными средствами разработки. Это приводит к тому, что объекты, отражающие одну сущность, имеют различные наименования и единицы измерения. Обязательная интеграция данных в ХД позволяет решить эту проблему.

     6. Минимизация избыточности информации. В ХД информация загружается из ОБД или OLTP-систем, при этом избыточность оказывается минимальной (около

     Все данные в хранилище данных делятся  на три основных категории:

     - метаданные;

     - детальные (текущие) данные;

     - агрегированные данные.

     Традиционные  подходы моделирования хранилищ данных основываются, как правило, на использовании временных отметок  создания записей и их модификации. На данный момент известны три основных способа моделирования времени  в хранилищах данных:

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

     2. Событийная модель используется  для моделирования событий (данных), возникающих в определенные моменты  времени. Данная модель подходит для моделирования транзакций, таких как: продажи, финансовые транзакции, складские операции и т.д.

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

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

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

     Очень часто информационно-аналитические  системы, создаваемые в расчете  на непосредственное использование  лицами, принимающими решения, оказываются чрезвычайно просты в применении, но жестко ограничены в функциональности. Такие статические системы называются Информационными системами руководителя (ИСР), или Executive Information Systems (EIS). Они содержат в себе множества запросов и, будучи достаточными для повседневного обзора, неспособны ответить на все вопросы которые могут возникнуть при принятии решений.

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

7. Оперативная аналитическая обработка (On-Line Analytical Processing, OLAP)

     Технология  комплексного многомерного анализа  данных получила название OLAP (On-Line Analytical Processing). OLAP - это ключевой компонент организации хранилищ данных. Концепция OLAP была описана в 1993 г. Эдгаром Коддом и имеет следующие требования к приложениям для многомерного анализа:

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

     предоставление  пользователю результатов анализа  за приемлемое время (обычно не более 5 с), ценой менее детального анализа;

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

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

     возможность обращаться к любой нужной информации независимо от ее объема.

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

     Рассмотрим  составные части OLAP-системы.

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

     Хранилище данных. Исходные данные собираются и  помещаются в хранилище, спроектированное в соответствии с принципами построения хранилищ данных. ХД представляет из себя реляционную базу данных (РБД). Основная таблица ХД (таблица фактов) содержит числовые значения показателей, по которым собирается статистическая информация.

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

     Сервер. Прикладной частью OLAP-системы является OLAP-сервер. Эта составляющая выполняет  всю работу (в зависимости от модели системы), и хранит в себе всю информацию, к которой обеспечивается активный доступ. Архитектурой сервера управляют различные концепции. В частности, основной функциональной характеристикой OLAP-продуктов является использование МБД либо РБД для хранения данных.

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