ОРГАНИЗАЦИЯ ЭЛЕКТРОННЫХ ХРАНИЛИЩ ДАННЫХ В УСЛОВИЯХ ЛЕЧЕБНОГО ПРОЦЕССА РОДИЛЬНОГО ДОМА

А.А.Сидоров, Е.Е.Ковшов, А.А.Устинов

Родильный дом №17 г.Москвы
(127591, Москва, ул. 800-летия Москвы, 22; т. 906-01-31)

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

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

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

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

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

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

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

В самом простом варианте для ХД используется модель данных, которая лежит в основе транзакционной системы [2]. Если транзакционная система функционирует на реляционной СУБД (Oracle, Informix, Sybase и т. п.), самой сложной задачей становится выполнение произвольных запросов, поскольку невозможно заранее оптимизировать структуру базы данных (БД) так, чтобы все запросы работали эффективно. Однако практика создания ХД показала, что существует зависимость между частотой запросов и степенью агрегированности данных, с которыми запросы оперируют, а именно круг пользователей, работающих с обобщенными данными, шире, чем тот, для которого нужны детальные данные. Это легло в основу подхода к поиску и выборке данных, называемого OLAP (On-line Analytical Processing). В основе OLAP лежит понятие гиперкуба, или многомерного куба данных [3], в ячейках которого хранятся анализируемые (числовые) данные, например, количество родившихся детей живыми. Измерения представляют собой совокупности значений других данных, скажем распределение детей по массе тела в граммах (от 500 до 999, от 1000 до 1499, от 1500 до 1999 и т.д.) и названия врожденных заболеваний, например пневмония, аномалии сердца, органов дыхания и др. В простейшем случае двумерного куба (квадрата) мы получаем таблицу, отображающую распределение детей, родившихся живыми, по массе тела. Дальнейшее усложнение модели данных может идти по нескольким направлениям:

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

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

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

Под витриной данных (Data Mart, ВД) понимается специализированное ХД, обслуживающее одно из направлений деятельности ЛУ, например для РД – учет наличия свободных койко-мест в отделениях РД или запасов медицинских препаратов. Важно, что происходящие здесь бизнес-процессы, во-первых, относительно изучены и, во-вторых, не столь сложны, как процессы в масштабах всего ЛУ. Количество сотрудников, вовлеченных в конкретную деятельность, также невелико (рекомендуется, чтобы витрина обслуживала не более 10-15 человек). Оптимальным подходом в технологии разработки ХД является параллельное внедрение ВД.

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

Для принятия обоснованных решений необходимо, чтобы доставляемая информация была актуальной и непротиворечивой. Поэтому организация процесса регулярной загрузки данных в ХД является важной задачей, при решении которой имеется ряд ключевых вопросов - например, какие данные должны быть помещены в ХД, как найти и извлечь эти данные, как обеспечить корректность данных в ХД и др. При описании технологии заполнения ХД будем различать три взаимосвязанные задачи: сбор данных (Data Acquisition), очистка данных (Data Cleansing) и агрегирование данных (Data Consolidation).

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

Второй аспект процесса сбора данных, который автоматизирован в некоторых продуктах, - это организация процесса пополнения ХД. В том же InfoPump, например, имеется возможность строить расписание пополнения ХД данными либо на временной основе, либо с использованием механизма событий [3].

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

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

Можно привести некоторые условия, при которых двухуровневая архитектура работает эффективно [2]:

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

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

На серверах также размещаются и ВД, но для обмена данными между ними приходится вводить так называемые переходники (Hub Servers). В крупных ЛУ требуется обеспечить возможность анализа данных как из ВД, так и непосредственно из ХД. Разница здесь определяется не столько размером БД (витрина может лишь ненамного уступать хранилищу), сколько тем, что ВД, как правило, не содержат детальных - не агрегированных данных. Это означает, что анализ ВД не требует глубокой детализации и часто может быть выполнен более простыми средствами.

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

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

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

Литература

Алан Р. Саймон. Стратегические технологии баз данных. М.: Финансы и статистика, 1999.- 479 с.: ил.
Корнеев В.В. Базы данных. Интелектуальная обработка информации. М.: Нолидж, 2000.-352 с., ил.
Дейт Дж. Введение в системы баз данных. К.: Диалектика, 1999.-846 с.
Трахтенгерц Э.А. Компьютерная поддержка принятия решений. М.: СИНТЕГ, 1998.-375 с.

Содержание конференции | Секция10