СППР с помощью хранилищ данных

Лидером пока считается компания Cognos, поставляющая продукты PowerPlay, Impromptu и Scenario. PowerPlay - это настольный OLAP-сервер, для извлечения данных из реляционных баз данных (Paradox, dBase, Clipper), "плоских" файлов и электронных таблиц (Microsoft Excel) используется генератор запросов и отчетов Impromptu. Затем специальный компонент, называемый Transformer, помещает извлеченные данные в клиентскую многомерную базу, которая называется PowerCube. Потребителям предоставляются широкие возможности по управлению PowerCube: передавать ее от пользователя к пользователю по запросу и принудительно, помещать на сервер для разделения доступа к ней или пересылать по электронной почте. Cognos постаралась сделать свой продукт максимально открытым: во-первых, PowerCube может быть помещен в реляционные базы Oracle, Informix, Sybase, MS SQL Server на платформах UNIX, HP/UX, Sun Solaris, IBM AIX, во-вторых, сам PowerPlay способен анализировать содержимое не только PowerCube, но и других многомерных баз данных.

Стоит отметить, что все эти фирмы  объединяет стремление включить в свои продукты компоненты, предназначенные  для Интеллектуального Анализа  Данных (Data Mining, ИАД). Например, усилия Business Objects и Cognos направлены на подготовку окончательных версий компонентов Business Miner и Scenario, соответственно, предназначенных именно для ИАД.

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

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

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

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

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

.

3. Интеллектуальный анализ  данных

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

Существует два подхода. В первом случае пользователь сам выдвигает  гипотезы относительно зависимостей между  данными. Фактически традиционные технологии анализа развивали именно этот подход. Действительно, гипотеза приводила  к построению отчета, анализ отчета к выдвижению новой гипотезы и  т. д. Это справедливо и в том  случае, когда пользователь применяет  такие развитые средства, как OLAP, поскольку  процесс поиска по-прежнему полностью  контролируется человеком. Во многих системах ИАД в этом процессе автоматизирована проверка достоверности гипотез, что  позволяет оценить вероятность  тех или иных зависимостей в базе данных. Типичным примером может служить, такой вывод: вероятность того, что  рост продаж продукта А обусловлен ростом продаж продукта В, составляет 0,75.

Второй подход основывается на том, что зависимости между данными  ищутся автоматически. Количество продуктов, выполняющих автоматический поиск  зависимостей, говорит о растущем интересе производителей и потребителей к системам именно такого типа. Сообщается о резком росте прибылей клиентов за счет верно найденной, заранее  неизвестной зависимости. Упоминается  пример сети британских универсамов, где  ИАД применялся при анализе убытков  от хищений товаров в торговых залах. Было обнаружено, что к наибольшим убыткам приводят хищения мелких "сопутствующих" товаров: ручек, батареек и т. п. Простой перенос прилавков  с этими товарами ближе к расчетным  узлам позволил снизить убытки на 1000%.

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

Процессы ИАД подразделяются на три большие группы: поиск зависимостей (discovery), прогнозирование (predictive modelling) и анализ аномалий (forensic analysis). Поиск зависимостей состоит в просмотре базы данных с целью автоматического выявления зависимостей. Проблема здесь заключается в отборе действительно важных зависимостей из огромного числа существующих в БД. Прогнозирование предполагает, что пользователь может предъявить системе записи с незаполненными полями и запросить недостающие значения. Система сама анализирует содержимое базы и делает правдоподобное предсказание относительно этих значений. Анализ аномалий - это процесс поиска подозрительных данных, сильно отклоняющихся от устойчивых зависимостей.

В системах ИАД применяется чрезвычайно  широкий спектр математических, логических и статистических методов: от анализа  деревьев решений (Business Objects) до нейронных сетей (NeoVista). Пока трудно говорить о перспективности или предпочтительности тех или иных методов. Технология ИАД сейчас находится в начале пути, и практического материала для каких-либо рекомендаций или обобщений явно недостаточно.

Необходимо также упомянуть  об интеграции ИАД в информационные системы. Многие методы ИАД возникли из задач экспертного анализа, поэтому  входными данными для них традиционно  служат "плоские" файлы данных. При использовании ИАД в СППР часто приходится сначала извлекать  данные из Хранилища, преобразовывать  их в файлы нужных форматов и только потом переходить собственно к интеллектуальному анализу. Затем результаты анализа требуется сформулировать в терминах бизнес-понятий. Важный шаг вперед сделала компания Information Discovery, разработавшая системы OLAP Discovery System и OLAP Affinity System, предназначенные специально для интеллектуального анализа многомерных агрегированных данных.

 

4. Разработка хранилища данных для врача-травмотолога

 

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

 

В основе современного подхода к информационному обеспечению

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

В процессе принятия решения о способе  лечения травмы врачу-травматологу необходимо знать следующее:

— вид травмы (перелом, вывих), степень  сложности травмы,

— анамнестические данные (пол, возраст, вес пациента);

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

— существующие способы лечения травм (фиксирующие устройства для оперативного и консервативного лечения).

В соответствии с необходимыми знаниями для принятия решения в хранилище  данных

загружается информация из нескольких баз данных: БД «Перелом», БД«Фиксирующее устройство», БД «Ограничение», БД «Анатомия» и др.

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

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

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

— изучить структуру локальных  баз данных;

— выделить для каждой такой БД подмножества данных, необходимых для загрузки в

хранилище;

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

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

 

4.2  Математическая  модель

 

При построении системы на базе хранилища  наиболее важным является этап определения  информационной потребности пользователя. С целью формализации описания информационной потребности, а также оптимизации  структуры хранилища, используется математическая модель хранилища данных, основанная на теоретико-множественном  подходе к описанию информационных потоков [4]. Теоретико-множественный  подход использует понятия: факты, измерения, аналитические срезы фактических  данных. Аналитические срезы фактических  данных — это представление данных по нескольким измерениям одновременно.

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

 

 

3.  Логическая модель хранилища данных

 

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

Запросы поддержки решения следуют  в такой последовательности: запрос выбирает

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

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

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

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

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