спарм

Archive for the ‘Наши публикации’ Category

Отчетность «По-министерски»

Вторник, Февраль 8th, 2011

(В.В.Пулит, «СП АРМ», Санкт-Петербург)

Невозможно управлять, не имея представлений о состоянии и поведении объекта управления. Это – аксиома, то есть истина, не требующая доказательств. Сложнее проникнуться пониманием того, информация весьма существенно может отличаться от Информации. Не все в порядке и с использованием терминов. Во многих случаях существенную, если не главенствующую, роль играет «дань моде».

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

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

Поясним сказанное на примере. По роду занятий (информатизация социальной сферы на региональном уровне) мы часто сталкиваемся со «стандартной статистической отчетностью» органов здравоохранения. Если рассматривать ее с позиций случайного внешнего наблюдателя – все просто замечательно! Прежде всего – все при деле. Сотрудники ЛПУ (лечебно-профилактических учреждений) регулярно заполняют многочисленные отчетные «таблицы». Специалисты статистических подразделений Министерства (МинЗдравСоцРазвития) изобретают новые отчетные формы. Загружены предприятия по производству бумаги и прочее, и прочее, и прочее… Короче, все заняты и им некогда заниматься «всякими глупостями».

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

1. Что мы должны знать для того, чтобы правильно оценивать ситуацию?

2. Что нас в ситуации не устраивает и что нам хотелось бы изменить?

3. Какими возможностями для претворения в жизнь необходимых преобразований мы располагаем?

4. Какая информация нам необходима для подготовки эффективного управленческого решения?

5. Где и как ее можно получить и как необходимо использовать при подготовке решения?

6. Как можно оценить влияние принятых (реализованных) нами решений на изменение ситуации?

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

Что же мы имеем на практике? На языке вертится термин «Иллюзорная информатизация». Во-первых, подавляющее число управленцев не смогут внятно ответить на приведенные выше вопросы. Во-вторых, на сегодняшний день не существует эффективных механизмов контроля достоверности, актуальности и полноты данных, поступающих на уровень Министерства. Дело в том, что то, что однажды было «просуммировано», последующему разделению на исходную информацию не поддается. Понять, является ли «неточное число» в отчете результатом небрежности оператора, или изменено сознательно, принципиально невозможно.

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

Но и в процессе компьютеризации базовых лечебных учреждений не все так гладко. Временами возникает ощущение, что в этом направлении деятельность управленческих структур связана не столько со стандартизацией методов информационного взаимодействия и с разработкой методик оценки эффективности работы ЛПУ, сколько с «решением задач» по продвижению информационных продуктов, разработанных дружественными для них организациями. В целом, их можно понять. Дело-то хлопотное. Дилетантов в информационных технологиях становится все меньше. Обеспечение «победы» нужного претендента – задача трудоемкая. На другие проблемные области времени может и не хватать…

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

· Число общих анестезий оперированным…___

· Умерло в результате общей анестезии…___

Ну и что? Мы не собираемся оспаривать утверждение, сто смертность среди пациентов – один из важных показателей. С нашей точки зрения, не менее интересным было бы узнать, сколько было зафиксировано случаев «Полного выздоровления» и сколько человек после операций стали инвалидами. Но в отчетах таких данных, к сожалению, не предусмотрено. Какие же выводы можно сделать, исходя из знания статистики? Даже при одновременном рассмотрении отчетов по предыдущим годам (если в них присутствуют аналогичные показатели, что не всегда так), вряд ли можно придумать что-либо более существенное, чем: «Смертность от общей анестезии повысилась/понизилась на ХХ %».

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

· Заболевания и их стадии

· К каким социально-демографическим группам относились пациенты?

· Сопутствующие диагнозы

· Использованные анестетики (производитель, наименование, партия, дозы…)

· Длительность операций

· Уровни подготовки и опыт хирурга и анестезиолога

· Аллергические реакции пациентов и т.д.

Ничего из перечисленного в статистических отчетах, естественно, быть не может. Вывод: статотчет (в лучшем случае!) – не более чем инструмент формирования «сигнала опасности». Хорошо, если сигнал будет принят и идентифицирован. Что дальше? А дальше, необходимо выбрать исследовательский центр, который по крупицам будет собирать необходимую информацию и лет через несколько, подготовив к защите парочку диссертаций, выдаст свои рекомендации, устаревшие на эти самые «несколько» лет.

Считаем, нет необходимости в дополнительной аргументации точки зрения, что статистическая отчетность в вопросах управления малоэффективна. В настоящее время каждый статистический отчет – это набор чисел, вмороженных в структуру чьей-то фантазии, или, если угодно, «гипотезы». Любое изменение парадигмы управления, на которую конкретный отчет был ориентирован (если действительно был), обрекает его на полную ненужность. Параллельно с этим превращаются в «макулатуру» и залежи годами накапливаемых данных. Их даже нельзя будет сравнивать с новыми статистическими показателями.

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

Как в свое время высказывался Великий кормчий (смотри соответствующие цитатники, выпускавшиеся в КНР в шестидесятых годах прошлого века): «Критиковать все мы мастера». Не останавливаясь на ключевом вопросе русской интеллигенции: «Кто виноват?», перейдем сразу к ответам на два следующих: «Что делать?» и «С чего начать?».

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

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

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

2.1. Минимально допустимый набор данных, вносимых в локальные медицинские информационные системы (МИС) ЛПУ в процессе их эксплуатации, и структуру информационных связей между ними;

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

2.3. Структуру данных, передаваемых из ЛПУ в органы территориального управления, и порядок их подготовки. При этом речь идет не о статистических сводках, а о первичной информации;

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

2.5. Сроки внедрения и ввода в промышленную эксплуатацию локальных МИС для каждого ЛПУ.

3. Для обеспечения возможности формирования на уровне региональных органов управления массивов совместно обрабатываемых данных необходимо:

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

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

4. Контроль для вновь внедряемых (эксплуатируемых в настоящее время) МИС возможности:

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

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

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

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

5. Отказ от формирования «стандартной» статистической отчетности на уровне ЛПУ. Все необходимые для разработки произвольных аналитических запросов и для подготовки проектов управленческих решений сведения (фрагменты первичных информационных массивов, поставляемые ЛПУ), соответствующие инструменты и технологии должны находиться в распоряжении профильных специалистов органов регионального управления (Министерства). Аналитические возможности локальных МИС должны использоваться исключительно с целью удовлетворения информационных потребностей конкретных ЛПУ. Сюда, в частности, можно отнести: внутреннюю отчетность, мониторинг запасов, электронный документооборот, подготовку справок по запросам внешних организаций (ЛПУ, МСЭ, ЗАГС, Органы СЗН…) и пр.

6. Решению о согласованном изменении (расширении) состава понятий (реквизитов), используемых территориальными ЛПУ в своих МИС, в обязательном порядке должна предшествовать последовательность действий:

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

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

6.2.1. Чего мы хотим добиться в результате (вид и предпочтительное значение «функции цели»)?

6.2.2. Что представляет собой методика определения степени приближения системы к ожидаемому результату (критерии, оценка динамики приближения, факт достижения приемлемого результата…)?

6.2.3. Что необходимо делать, если в результате реализации подготовленного управленческого решения значение контролируемых параметров …?

6.3. Определение состава данных и методов их обработки (способов использования), на основе которых могут быть получены значения необходимых показателей. Какими структурами и в рамках каких процессов эти данные должны порождаться? Какие значения эти данные могут принимать и каким «форматам» должны соответствовать?

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

Отсюда можно сделать вывод, что если органы управления действительно хотят Управлять, они, как минимум, должны:

1. Пользоваться объективной информацией, на которой не отразилась попытка «подыграть» желаниям руководителя. То есть, для анализа состояния системы и подготовки управленческих решений необходимо пользоваться первичными данными, используемыми ЛПУ для решения текущих задач, а не для отчетности.

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

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

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

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


Задачи, поддерживаемые МИС

Вторник, Февраль 8th, 2011

(«СП.АРМ», Санкт-Петербург)

Приняв решение о приобретении медицинской информационной системы (МИС) потенциальный пользователь должен, прежде всего, сформировать четкое представление о том, в каких задачах он собирается ее использовать. Выбирая продукт необходимо, как минимум, сопоставить его возможности со своими пожеланиями. Вполне может оказаться, что для удовлетворения всех запросов Заказчика, учитывающих «уникальность» конкретного ЛПУ, необходима самостоятельная разработка.

Необходимо, однако, всегда принимать во внимание, что стоимость «персональной» разработки может в несколько раз(!) превысить цену готового к внедрению программного обеспечения (ПО). Кроме того, существует риск получения, в итоге, отрицательного результата. Наконец, процесс начала промышленной эксплуатации будет перенесен, в лучшем случае, на полтора – два года. В отличие от этого, качественные информационные системы медицинского направления, предлагаемые в настоящее время на рынке программных продуктов, обладают широким спектром настроек. С их помощью обеспечивается возможность адаптации конкретного приложения практически ко всем особенностям процесса оказания медицинской помощи.

После того, как Заказчик сформулирует свои пожелания, он должен их доходчиво довести до поставщика (разработчика) ПО. После чего рекомендуется убедиться, что все понято правильно и что полное взаимопонимание достигнуто.

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

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

1. Функционал программного обеспечения полностью удовлетворяет Заказчика и он готов сразу подписать контракт на поставку. Данная ситуация возникает крайне редко. Заказчик, при этом, или не во всем разобрался, или не задумывается о перспективах развития своей организации.

2. Ознакомившись с возможностями продукта, заказчик готов отказаться от используемой им технологии оказания медицинских услуг и перейти на вариант методики, заложенной в качестве основы эффективного функционирования информационной системы в процессе ее проектирования. Этот случай на практике встречается также крайне редко, хотя с точки зрения стандартизации он не так уж и плох. Данный вариант соответствует, так называемым, «коробочным» (Case) программным продуктам. Девизом их продвижения на рынке является – «установи и работай»! (Авторам, правда, случаи успешной эксплуатации пока неизвестны).

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

4. Система, по заверениям Продавца, может быть доведена до уровня, полностью удовлетворяющего пожеланиям Заказчика, после «незначительной» доработки. На практике этот вариант встречается чаще других. Потребителю, однако, необходимо учитывать ряд возможных «осложнений». К ним, в частности, относятся случаи, когда архитектура системы не поддерживает возможности подключения дополнительных задач, когда СУБД, использованная при разработке приложения, имеет ограничения в части масштабирования, когда организация-Поставщик не является разработчиком ПО или когда система принципиально не допускает развития (внесения каких-либо изменений).

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

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

Таким образом, Заказчик получает возможность уточнять и конкретизировать свои пожелания с учетом уже реализованных задач, или возможности их реализации. В то же время, «примечания Разработчика» могут предотвратить появление «Маниловских идей», связанных, например, с желанием перевести больницу в автоматический режим работы без участия человека. В последнем случае взаимоотношения Заказчика и Разработчика рискуют превратиться в чреду взаимных претензий и завершиться с чувством глубокой обиды и неудовлетворенности, как с одной, так и с другой стороны.

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

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

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

3. Электронный документооборот в рамках лечебного процесса.

4. Стандартизацию задач обследования и выбора варианта лечения (использование принятых в ЛПУ лечебных стандартов) в соответствии с установленным диагнозом и нозологической формой проявления заболевания.

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

6. Перевода в «фоновый режим» задач подготовки установленной периодической статистической отчетности.

7. Автоматизацию процесса информационного взаимодействия со страховщиками (ОМС, ДМС) в рамках задач оплаты предоставленных пациенту услуг.

8. Эффективный информационный обмен с внешними по отношению к ЛПУ клиническими лабораториями, диагностическими центрами и другими организациями системы здравоохранения.

В качестве «побочных», но не менее важных для ЛПУ направлений использования порождаемых системой информационных ресурсов, могут рассматриваться:

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

2. Управление «Столовой» (учет продуктов, составление меню, организация диетического питания и пр.).

3. Учет реальной загрузки специалистов, коек и оборудования.

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

5. Оценка эффективности работы структурных подразделений клиники.

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

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

b. Соотношению удовлетворенного и неудовлетворенного спроса на медицинские услуги с выделением вероятных причин проявления негативных тенденций.

c. Оценке эффективности работы различных ЛПУ исходя из данных мониторинга их деятельности.

d. Оценке достаточности региональных ресурсов системы здравоохранения (сеть, персонал, профили ЛПУ, оборудование и т.д.) для удовлетворения запросов населения и пр.

7. Эффективное информационное взаимодействие со структурами другой ведомственной принадлежности (МСЭ, СЗН, ПФ РФ, Фонд социального страхования и т.д.).

Информационная поддержка МИС не распространяется, как правило, на такие направления, как:

1. Бухгалтерский учет и отчетность.

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

3. Административный документооборот: переписка, внутренние приказы и распоряжения, внешние договора и пр.

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

Тем не менее, для обеспечения эффективности решения связанных с перечисленными направлениями задач поддерживается процесс автоматизированного обмена данными с соответствующими специализированными информационными продуктами. Например, при использовании организацией бухгалтерского пакета «Парус», активно используется перенос данных в МИС по штатным единицам, а обратно – о реестрах предоставленных услуг с их стоимостью.

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

Что касается собственно «Tаблицы», связывающей задачи ЛПУ с возможностью их информационной поддержки со стороны МИС, состав ее «полей» интересует нас в следующем наборе: «Общее направление работ ЛПУ» → «Составляющие его задачи» (верхний уровень детализации) → «Факт возможности их информационной поддержки на базе ресурсов МИС» → «Альтернативные варианты решения рассматриваемой задачи». Приведенный пример фрагмента такой таблицы, в которой интересующие Заказчика задачи должны сочетаться с комментариями Разработчика, относится функционалу одной из современных МИС, к продукту компании «СП.АРМ», Санкт-Петербург (МИС «qMS»).

Критерии эффективности региональных МИС

Вторник, Февраль 8th, 2011

В.В. Пулит. «СП.АРМ» -Санкт-Петербург

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

Надежды, к сожалению, не оправдались. Отсутствие единой концепции и стандартов проектирования МИС (медицинских информационных систем) привело к тому, что оказалось гораздо проще (и экономически целесообразнее!) отказываться от используемых «локальных» разработок в пользу более совершенных. Дешевле было приобрести новую и сравнительно недорогую информационную систему и постараться внести в нее уже накопленные данные, чем пытаться объединять ресурсы баз данных, спроектированных для различной логики эксплуатации.

На начальных этапах это было вполне допустимо. Однако после того. Как системы информационной поддержки ЛПУ стали ориентироваться на комплексные подходы, ситуация резко изменилась. Сегодня переход на новую информационную систему зачастую равносилен радикальному пересмотру методик оказания медицинских услуг или созданию новой организационной структуры клиники. То есть, «старые» МИС начинают тормозить развитие, а их замена равносильна полной остановке процесса оказания услуг.

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

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

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

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

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

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

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

3. Наличия методик оценки эффективности и результативности функционирования системы и связанных с указанными методиками критериев.

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

5. Использования методов выявления взаимного влияния (связи) между рассматриваемыми показателями и зависимости рассматриваемых показателей от реализованных управленческих решений.

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

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

2. Минимизация клавиатурного ввода данных в систему в процессе общения с пациентом или при предоставлении ему медицинских услуг. Исключение, по возможности, внесения данных в систему вне рамок приема пациентов или во внерабочее время.

3. Наличие в системе всех необходимых специалистам справочников с возможностью их расширения (пополнения) и с учетом удобства использования.

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

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

6. Однажды занесенная в систему информация не может быть безвозвратно уничтожена. Все случаи ее корректировки должны протоколироваться и однозначно связываться с конкретным исполнителем.

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

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

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

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

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

12. Присутствие в системе методик и механизмов актуализации данных и их синхронизации с внешними информационными массивами.

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

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

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

Кроме автоматизации ряда задач, связанных с работой медицинского персонала, система изначально (в варианте базовой поставки) должна, как на уровне ЛПУ, так и региона в целом, поддерживать такие аналитические запросы, как:

1. Исследование динамики спроса на медицинские услуги.

2. Сопоставление удовлетворенного и неудовлетворенного спроса (желательно, с выяснением причин отказа от предоставления необходимых услуг).

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

4. Загрузка и эффективность использования имеющихся ресурсов.

5. Финансовая эффективность предоставления услуг, определение их реальной себестоимости, прибыльность и т.п.

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

1. Унифицировать процессы и повысить качество проектирования МИС.

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

3. Существенно повысить эффективность использования территориальных ресурсов ( в том числе, информационных).

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

5. Снизить объемы финансирования и сократить сроки ввода в промышленную эксплуатацию МИС в рамках новых информационных проектов (снижение уровня протекционизма, использование проверенных на практике решений, внедрение модернизируемых систем и т.д.).

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

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

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

Вторник, Февраль 8th, 2011

В.В. Пулит. «СП.АРМ» -Санкт-Петербург

Любая информационная система решает, по существу, три равные по значимости задачи:

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

2. Обмен данными в рамках совместно решаемых задач.

3. Мониторинг состояния организации, формирование внутренней и стандартной (внешней) отчетности, информационная поддержка управленческих решений.

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

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

§ «Продолжать развитие, ничего не меняя»;

§ «Узнать здесь и сейчас все обо всем».

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

В то же время, вполне допустимый (возможный) отказ от «бумажного» документооборота внутри организации без дополнительных затрат способен на 20 – 30 процентов повысить производительность труда. В самом деле, зачем тратить время на подготовку и распечатку десятков экземпляров ежедневных отчетов, когда аналогичную, по сути, операцию (и без усилий!) может провести любой, для кого соответствующие данные представляют интерес? Зачем «врачебным почерком» делать записи в рецептах и истории болезни, если вся информация и так хранится в системе и в любой момент может быть разборчиво распечатана или выведена на экран монитора? В любой момент она доступна для любого специалиста, обладающего, естественно, необходимыми правами доступа. И, кстати, познакомиться с содержанием печатного документа, как правило, бывает гораздо проще, чем получить доступ к документу, хранящемуся в электронном виде.

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

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

К большому сожалению «местные горе статистики» в стремлении удовлетворить собственное любопытство упускают из рассмотрения четыре основополагающих подхода к отчетности:

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

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

a. Как и кем необходимая для справки информация порождается, как хранится, как обеспечивается ее достоверность, полнота и актуальность?

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

c. В какой реально необходимой структуре и в каких форматах данные должны быть предоставлены конечному «потребителю» для их «комфортного» восприятия и использования?

d. Кем, в каких задачах и как часто эта информация будет использоваться? Полезно, также, предложить методику использования данных отчета (справки) в рамках подготовки того или иного управленческого решения по схеме: «Если, то…».

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

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

Авторы, конечно, далеки от желания организовать бессмысленный в современных условиях «крестовый поход» против ветряных мельниц стандартной отчетности, хотя и не исключают возможной полезности этого предприятия. То, что утверждено на уровне министерства придется выполнять, по крайней мере, в ближайшей перспективе. Но поощрять подобные тенденции на уровне ЛПУ принципиально ошибочно! Желание администрации формировать избыточную по содержанию отчетность необходимо пресекать в корне.

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

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

1. Повышения качества оказания услуг и удовлетворения существующего (прогнозируемого) спроса.

2. Повышения результативности работы организации.

3. Повышения эффективности использования доступных ресурсов.

4. Повышения эффективности планирования развития организации и выявления возникающих тенденций спроса на услуги.

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

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

1. На этапе предпроектного обследования организации Заказчика целесообразно провести анкетирование, целью которого является определение структуры используемого («бумажного») документооборота. При этом проясняются вопросы:

a. Кем и в каких процессах информация порождается (или преобразуется)?

b. Куда она передается и как там используется (обрабатывается, трансформируется)?

c. В каких случаях и как полученная информация влияет на изменение действий специалистов или подразделений?

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

2. В структуре существующего документооборота необходимо выделить следующие группы:

a. Документы строгой отчетности, скрепляемые печатью организации и передаваемые в архив (пересылаемые во внешние организации) для учета и хранения в виде «стандартных» бланков.

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

c. Документы, используемые для мониторинга текущего состояния организации:

§ Запасы

§ Свободные «мощности» и пр.

d. Документы (данные), необходимые для планирования и подготовки управленческих решений:

§ Динамика обращений по услугам

§ Эффективность работы подразделений и специалистов

§ Динамика изменения показателей работы организации

§ Тенденции спроса

§ Динамика соотношений спроса и предложения

§ Эффективность загрузки ресурсов и т.д.

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

a. Замене «бумажных» носителей электронными;

b. Формированию (по мере необходимости) печатных копий документов или их экранных отображений самими специалистами;

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

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

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

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

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

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

При готовности сторон к компромиссу и обоснованным взаимным уступкам будет:

1. Достигнуто существенное сокращение времени, затрачиваемого на подготовку и обработку данных.

2. Обеспечено формирование инструментов динамического (в реальном масштабе времени!) мониторинга запасов и загрузки ресурсов организации.

3. Реализовано автоматическое отслеживание критических показателей работы организации (объем запасов, загрузка ресурсов, доступный бюджет, нормативы выработки и пр.).

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

5. Организовано автоматическое (автоматизированное) формирование пакета документов стандартной отчетности.

6. Стимулировано более активное и сознательное использование данных аналитических справок (отчетов) при подготовке управленческих решений.

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

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

В качестве своеобразного обобщения сказанному можно перечислить ряд вопросов (последовательных шагов), решение (реализация) которых обеспечивает разработчику возможность сформировать более ли менее ясное представление о том, чего же от него «хочет» Заказчик.

Анализ со стороны Заказчика (стратегическая составляющая):

1. Формулировка Цели, достижению которой должен способствовать разрабатываемый Запрос.

2. Какие варианты организационных мероприятий могут способствовать достижению поставленной цели?

3. Какие из существующих «рычагов управления» могут реально влиять на проведение указанных мероприятий?

4. Какая информация должна иметься в распоряжении Администрации Заказчика для выработки эффективных управленческих решений в рамках достижения рассматриваемой Цели?

5. На основе обработки (анализа) каких данных может быть получена необходимая информация?

6. Какие алгоритмы обработки данных с точки зрения Заказчика целесообразно использовать для получения необходимой информации?

7. Какие возможности для изменения (фильтрации) исходной информации должны присутствовать в запросе?

8. Как предполагается использовать результаты обработки Запроса в процессе подготовки управленческого решения (как результат Запроса будет влиять на выбор варианта решения)?

Анализ со стороны Заказчика («тактическая» составляющая):

1. Как часто запрос будет использоваться (единственный раз, редко, периодически[1], постоянно, ежедневно, несколько раз в день)?

2. Каков минимальный промежуток времени от занесения в систему данных до обработки запроса?

3. Какие структуры (специалисты) будут заносить в систему исходные данные и какие структуры (специалисты) будут использовать результат обработки запроса?

4. В каких задачах (помимо достижения стратегической Цели) и кем могут использоваться результаты Запроса?

Анализ со стороны Разработчика:

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

2. Возможность их использования с учетом предлагаемых Заказчиком алгоритмов их обработки.

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

4. Предложение по вариантам корректировки методов работы организации[2], связанное с оптимизацией результатов обработки подготовленного Запроса.


Достижение соглашения между Заказчиком и Разработчиком по вопросам:

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

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

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

4. Возможности реализации Запроса по предлагаемой постановке силами специалистов Заказчика (при консультационной поддержке со стороны Разработчика).


[1] С какой периодичностью?

[2] С точки зрения порождения, хранения и обработки данных.

[3] С точки зрения порождения, хранения и обработки данных.

Влияние ресурсов МИС на изменение подходов к выбору вариантов и методик лечения

Вторник, Февраль 8th, 2011

А.Н. Долженков, А.В. Мартынов, В.В. Пулит (АОЗТ «СП.АРМ», Санкт-Петербург)

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

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

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

a. Регистрацию пациентов;

b. Занесение в систему сопутствующей информации, необходимой для принятия решения о выборе варианта лечения;

c. Использование необходимых в работе специалиста словарей, справочников и классификаторов, хранящихся в электронном виде и снабженных эффективной системой поиска;

d. Инструменты сортировки и поиска пациентов, объединения их в группы, формирования списков и т.д.

e. Автоматизация часто повторяющихся рутинных операций;

f. Использование контекста решаемых задач для оптимизации экранных форм отображения данных;

g. Использование шаблонов выходных печатных документов и прочее.

2. Использование информационной системы в качестве инструмента подготовки оперативных (тактических) управленческих решений. В эту группу задач входят:

a. Анализ загрузки имеющихся ресурсов (ежедневная, еженедельная, месячная и квартальная отчетность);

b. Сопоставление номенклатуры востребованных, предоставленных и имеющихся ресурсов;

c. Анализ состояния и динамика изменения запасов;

d. Доходность организации в разрезе подразделений и предоставляемых медицинских услуг;

e. Заполнение штатов и проверка соответствия квалификации сотрудников уровню решаемых ими задач;

f. Наличие очередей на предоставление медицинских услуг, в том числе с учетом специалистов;

g. Результативность предоставления медицинских услуг и т.д.

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

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

b. Возможности по обеспечению поддержки согласованных регламентов информационного обмена;

c. Унификацию структуры и форматов выгружаемых (передаваемых) во внешние информационные системы блоков данных;

d. Возможность реализации внешних подключений к ресурсам локальных информационных систем (информационных систем отдельных ЛПУ);

e. Унификация процедур проведения поисковых запросов на «распределенных» массивах данных и т.п.

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

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

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

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

i. Выявление слабо формализуемых связей между совместно рассматриваемыми процессами;

ii. Реализация произвольных аналитических срезов на генеральных выборках первичной информации;

iii. Возможность анализа динамических изменений параметров системы с произвольной дискретностью и пр.

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

i. Контролируемые показатели;

ii. Критерии эффективности;

iii. Стандартные алгоритмы сопоставления и пр.

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

f. Возможность прямого сопоставления предлагаемых и востребованных медицинских услуг;

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

h. Возможность совершенствования законодательной базы, исходя из анализа причин появления «узких мест» в лечебных процессах;

i. Проектирование развития системы здравоохранения территории или ее структурных элементов на основе анализа:

i. Неудовлетворенного спроса;

ii. Тенденций и причин изменения спроса на те или иные медицинские услуги;

iii. Имеющихся ресурсов по финансированию проектов в области здравоохранения;

iv. Доступной для территориальных ЛПУ ресурсной базы;

v. Прогнозируемого «отклика» системы на ресурсные вложения и т.п.

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

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

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

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

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

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

Даже в условиях стационара лечение начинается, как правило, с «чистого листа». Никто не будет тратить время на попытку ознакомления с документами, хранящимися в различных ЛПУ, которые пациент посещал в течение жизни. Иными словами, решение по выбору варианта лечения будет принято на основе анализа единственного среза данных, полученного в рамках ограниченного временного интервала.

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

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

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

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

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

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

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

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

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

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

2. Формирование «библиотеки» корреляционных зависимостей между показателями жизнедеятельности и здоровьем человека. Задача: определение структуры данных, хранение и обработка которых должны обеспечиваться информационной системой. Цель: разработка механизмов, позволяющих выявлять тенденции изменения здоровья по данным периодических наблюдений (по сопоставлению ряда наблюдений). Результат мог бы радикально повлиять на раннюю диагностику онкологических и сердечнососудистых заболеваний.

3. Формирование «библиотеки» корреляционных зависимостей между показателями жизнедеятельности и возрастом человека. Задача: сопоставление изменений в показателях функциональной диагностики и анализах, определяемых состоянием здоровья и возрастом человека. Цель: возможность корректировки диагноза и методики лечения с учетом возраста конкретного пациента.

4. Формирование «библиотеки» постановок по запросам, связанным с формированием (с выборками) временных рядов зависимостей показателей жизнедеятельности пациента. Задача: использование постановок при реализации библиотеки соответствующих каталогизированных запросов. Цель: создание инструмента, позволяющего конечному пользователю (специалисту-медику с базовым уровнем компьютерной подготовки) быстро и корректно получать зависимости показателей по анализам и функциональной диагностике, необходимые ему для корректировки диагноза или назначения лечения.

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

6. Подготовка предложений по оптимальному уровню унификации информационных систем, используемых различными медицинскими учреждениями. Задача: анализ и согласование структуры и форматов данных, используемых различными МИС, представляющих интерес для родственных ЛПУ. Цель: обеспечение сопоставимого уровня информационной поддержки и качества услуг, предоставляемых различными лечебными учреждениями региона; повышение эффективности процесса обобщения и совместной обработки данных.

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

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

Аналитическая обработка данных в интерпретации расширенной реляционной модели RM/T

Пятница, Декабрь 19th, 2008
Тимофеев Д.В.
Санкт-Петербургский институт информатики и автоматизации РАН
В данной работе рассматривается интеграция аналитической обработки данных в иерархиче-скую модель данных с горизонтальными связями, которая является интерпретацией расширен-ной реляционной модели RM/T.
1. Введение
В работе [1] была предложена интерпретация расширенной реляционной модели данных RM/T [2]. Согласно этой интерпретации молекулярные типы RM/T могут быть описаны структурой дерева с горизонтальными связями, дерево должно быть логическим, что позволит легко решать задачи переструктуризации дерева. Для такой структуры должна поддерживаться возможность представления горизонтальных связей в виде логических деревьев. Суррогаты должны служить для упорядочивания кортежей. Также было предложено использовать для описания этой интерпретации модели данных RM/T модель данных XML, наконец, было представлено краткое описание разработанной расширенной модели данных, основанной на модели данных RM/T, для описания которой используется модель данных XML.
В разработанной расширенной модели данных иерархическая модель данных в варианте XML наложена как вторичная поверх реляционной. Это позволяет сохранить строгость реляционной модели и привнести в неё дополнительные преимущества иерархической модели, а также использовать для описания модели как реляционную алгебру, так и языки и стандарты платформы XML: XML [3], Relax NG [4], Schematron [5], DOM [6], XPath [7, 8], XQuery [9].
Основными структурными компонентами разработанной модели данных являются понятие, объект, экземпляр объекта, код экземпляра объекта, отображение.
Объекты соответствуют типам элементов XML-документа, экземпляры объектов – отдельным элементам, а понятия – атрибутам элементов. С другой точки зрения объекты соответствуют реляционным отношениям, экземпляры объектов – кортежам отношений, а понятия – атрибутам отношений (рис. 1).


Рис 1. Структурные компоненты модели данных

Если с точки зрения XML позиция элемента это ключ естественный, то чисто с реляционной точки зрения он видится как ключ суррогатный. В разработанной модели данных этот ключ называется кодом экземпляра объекта.
Для описания связей понятий с объектами, а также связей между объектами вводится ещё одна структура – отображение. Отображение включает схему дерева объектов и дерево экземпляров. Дерево объектов соответствует схеме ХML-документа и может быть описано с помощью языка Relax NG [4], а дерево экземпляров – множеству ХML-документов, удовлетворяющих этой схеме.
Базу данных предлагается моделировать как совокупность деревьев информационных объектов с горизонтальными связями и со специфичным для каждого объекта набором понятий.
Для идентификации отображений, объектов и понятий предлагается использовать уникальные в пределах базы данных короткие коды. Относительно этих кодов определяются ограничения це-лостности и операции.
Так как задачей является построение логической структуры с возможностью переструктуризации, то и иерархические связи, и горизонтальные связи реализуются только на основе значений понятий, таким образом, все связи являются информационными.
В код экземпляра помимо первичного позиционного ключа объекта, включаются также внешние ключи, ссылающиеся на экземпляры-предки данного экземпляра (рис. 2).


Рис. 2. Реализация иерархических связей

Такой иерархический позиционный первичный ключ определяет уникальность экземпляра не только в пределах родительского экземпляра, но и в пределах любого экземпляра-предка. Используя метод редукции ключа, можно получить доступ к любому предку данного экземпляра объекта. Поэтому, несмотря на избыточность данных, такой ключ является наиболее предпочтительным, он позволяет реализовать и поддерживать иерархические связи автоматически.
Горизонтальные связи реализуются пользователем с помощью механизмов пользовательских потенциальных и внешних ключей объектов.
В модели данных предусматриваются ограничения целостности: ограничения типов и понятий, ограничения объектов и ограничения базы данных. Ограничения целостности могут быть описаны с помощью языка Schematron [5]. Благодаря выбранной структуре кодов экземпляров, правила целостности сущностей и правила ссылочной целостности для иерархических связей поддерживаются автоматически.
В модели данных предлагается поддерживать не только спецификационные операции, но и навигационные операции манипулирования данными, так как они предоставляют большую гибкость и свободу в реализации конкретных задач. Навигационные операции соответствуют низкоуровневым операциям модели DOM [6] с некоторыми расширениями. Спецификационные операции соответствуют реляционной алгебре с расширением операций на деревья объектов. Спецификационные операции могут быть описаны с помощью языка XQuery [9].
Для логической переструктуризации дерева предлагаются механизмы ссылочных и виртуальных объектов.
В данной работе рассматривается аналитическая обработка данных в разработанной модели данных. Аналитическая обработка связана с получением многомерного представления данных, такое представление в свою очередь может быть описано древовидной структурой, то есть, основной структурой предложенной модели данных, поэтому интеграция аналитической обработки в модель данных выглядит целесообразной.
Конкретной задачей работы является представление механизма интеграции аналитической обработки в разработанную модель данных.
2. Аналитическая обработка данных
Ещё с давних времён в обработке информации выделялись два уровня: оперативный и аналити-ческий. Аналитическая обработка заключается в группировании и обобщении (агрегации) дан-ных в любом виде, необходимом аналитику [10]. Группирование обычно выполняется в соот-ветствии со многими различными критериями.
Аналитическую обработку предлагается выполняться в рамках одного отображения. Смысл аналитической обработки состоит в установлении функциональной зависимости множества Y, получаемого из множества значений одного понятия D, от множеств X1, X2, …, Xn, получаемых из множеств значений других понятий A1, A2, … An: Y(X1, X2, …, Xn). Под функциональной за-висимостью Y(X1, X2, …, Xn) понимается, что одному элементу x1i, x2i, … xni соответствует один и только один элемент yi.
Предполагается, что можно одновременно построить несколько функций от одних и тех аргу-ментов: Y1(X1, X2, … Xn), Y2(X1, X2, … Xn), …, Ym(X1, X2, … Xn), задав их на значениях понятий D1, D2, …, Dm и понятий A1, A2, … An.
Переменные X1, X2, … Xn являются независимыми, а переменная Y – зависимой. Зависимость может быть представлена в виде многомерного массива или гиперкуба. Независимые перемен-ные составляют размерность массива и называются измерениями. Значения зависимых пере-менных содержатся в ячейках массива и называются мерами (фактами).
Агрегирование
Одно значение понятия A может быть связано с 0, 1 или несколькими значениями понятия D. При построении функциональной зависимости Y(X) значения A, не связанные ни с одним зна-чением из D, могут быть отброшены, а оставшиеся значения A, в простейшем случае, могут об-разовать множество X. В более сложном варианте X может быть агрегировано из A, типичный пример – округление, при котором несколько A округляются до одного и того же X. Таким об-разом, устанавливается функциональная зависимость X=X(A) (рис. 3).
Для значений X, связанных с несколькими значением из D, проводится агрегирование этих зна-чений D в один элемент Y. Наиболее часто употребляемые варианты агрегирования – просто количество связанных значений (Num), их сумма (Sum), минимальное из значений (Min), мак-симальное из значений (Max), их среднее арифметическое (Mid). Таким образом, устанавлива-ется функциональная зависимость Y=Y(D) (рис. 3).


Рис. 3. Агрегация

Часто возникает необходимость в дополнительном преобразовании значений до их агрегирова-ния. Для этого в данной работе предлагается задавать различные выражения аналитики.
В общем случае выражения аналитики могут использоваться:
для дополнительного преобразования значений А до их агрегирования в X;
для агрегирования значений А в X;
для дополнительного преобразования значений D до их агрегирования в Y.
В выражении можно пользоваться различными функциями, а также переменными, в частности переменной Z, содержащей значение текущего понятия.
Приведём два примера:
Если значения A представляют собой ширину, то каждое из них может быть умножено на дли-ну (однозначно определяемое значение некоторого понятия, связанного с A), затем произведе-ние может быть округлено до целочисленной величины и использовано в качестве X:
$int(Z * $$Get(«Length»))
Если значения из D находятся в строковом формате, то, для возможности их агрегации к сред-нему арифметическому, они предварительно должны быть преобразованы к числовому виду:
$select(Z=»ПЕРВАЯ»:1, Z=»ВТОРАЯ»:2, Z=»ТРЕТЬЯ»:3, 1:0)
Результаты
Как было отмечено ранее, зависимости функций Y1(X1, X2, …, Xn), Y2(X1, X2, …, Xn), …, Ym(X1, X2, …, Xn) могут быть представлены в виде многомерного массива. В данной работе предлага-ется записывать результаты аналитической обработки в массив вида:
Analytics(A1, x1, A2, x2, …, An, xn, D1) = y1
Analytics(A1, x1, A2, x2, …, An, xn, D2) = y2
Analytics(A1, x1, A2, x2, …, An, xn, Dm) = ym
Analytics(A1, x1, A2, x2, D1) = y1
Analytics(A1, x1, A2, x2, D2) = y2
Analytics(A1, x1, A2, x2, Dm) = ym
Analytics(A1, x1, D1) = y1
Analytics(A1, x1, D2) = y2
Analytics(A1, x1, Dm) = ym
Analytics(D1) = y1
Analytics(D2) = y2
Analytics(Dm) = ym
Здесь:
Аi – код понятия аналитического среза (измерения);
xi – значение понятия аналитического среза Аi;
Dj – код понятия анализируемого признака (меры);
yj – значение понятия анализируемого признака Dj.
Таким образом, в такой массив записываются не только значения, но и коды понятий.
Следует отметить, что если задать аналитические срезы как последовательность A1, A2, … An, то группировка будет производиться по следующим сочетаниям:
(A1, A2, … An)
(A1, A2, …)

(A1, A2)
(A1)
()
Соответственно, для каждого сочетания будут вычисляться анализируемые признаки.
Такой массив в свою очередь предлагается представлять в виде дерева:
В этом дереве A1, A2, … An являются кодами объектов, x1, x2, … xn – кодами экземпляров, D1, D2, … Dm – кодами понятий объектов, y1, y2, … ym – значениями понятий.
Таким образом, массив содержит как дерево объектов, так и дерево экземпляров, соответст-вующее этому дереву объектов.
Подобная структура называется физическим деревом, так как иерархическая организация дан-ных в ней представлена явно. Соответственно, предложенные ранее структуры определяют ло-гическое дерево, в котором иерархическая организация данных представляется с помощью ко-дов экземпляров.
По такому массиву может быть автоматически построено специальное отображение аналитики.
Рассмотрим пример.
Имеется объект АВ (поставки) с понятиями S (коды поставщиков), P (коды деталей), QTY (ко-личество поставок) (рис. 4).


Рис 4. Пример аналитической обработки

Если установить первый аналитический срез по понятию S, второй – по понятию P, в качестве анализируемого признака задать понятие QTY и выбрать функцию агрегирования Sum, то мож-но будет ответить на следующие запросы:
определить общее количество поставок по поставщикам и деталям;
определить общее количество поставок по поставщикам;
определить общее количество поставок.
В результате выполнения аналитического запроса будет создан следующий массив:
Analytics(«S»,»S1″,»P»,»P1″,»QTY»)=300
Analytics(«S»,»S1″,»P»,»P2″,»QTY»)=200
Analytics(«S»,»S1″,»QTY»)=500
Analytics(«S»,»S2″,»P»,»P1″,»QTY»)=300
Analytics(«S»,»S2″,»P»,»P2″,»QTY»)=400
Analytics(«S»,»S2″,»QTY»)=700
Analytics(«S»,»S3″,»P»,»P2″,»QTY»)=200
Analytics(«S»,»S3″,»QTY»)=200
Analytics(«S»,»S4″,»P»,»P2″,»QTY»)=200
Analytics(«S»,»S4″,»QTY»)=200
Analytics(«QTY»)=1600
Этот массив может быть представлен в виде отображения (рис. 5).


Рис. 5. Отображение аналитики

В этом отображении объекты А1, А2 будут иметь тип массив. Такой объект является виртуаль-ным [11], так как он используется для представления данных, не существующих в базе данных. Операция для получения следующего кода экземпляра и значений понятия экземпляров вирту-ального объекта создаётся автоматически.
С помощью XQuery этот аналитический запрос может быть описан следующим образом:
let $view := doc(«view.xml»)
return
{
for $s in distinct-values($view//ab/@s)
order by $s
return
{
for $p in distinct-values($view//ab[@s = $s]/@p)
order by $p
return
}
}
В примере аналитические срезы и анализируемый признак заданы на понятиях одного объекта, однако в общем случае они могут задаваться на понятиях различных объектов, находящихся на различных уровнях иерархии.
3. Реализация
Предложенная модель данных является основой разработанного инструмента для построения и использования информационных систем qWORD-XML [12]. В инструменте аналитическую об-работку предлагается выполнять в рамках отображения (экранной формы). Отображение поми-мо всего прочего предоставляет собой визуальное средство для аналитической обработки дан-ных и для предоставления результатов этой обработки. Дополнительно предлагается возмож-ность предоставления результатов аналитической обработки в виде перекрёстной таблицы или в виде различных диаграмм.
Рассмотрим, реализацию описанного выше аналитического запроса. Исходные данные пред-ставлены в отображении на рис. 6.


Рис. 6. Отображение с исходными данных

Аналитический запрос задаётся в колонках дерева объектов (рис. 7).


Рис. 7. Аналитический запрос

Перед выполнением аналитической обработки можно организовать предварительный поиск данных по объектам и значениям их понятий. Условия поиска задаются в колонке Условия.
Колонка A предназначена для пометки понятий, значения которых будут использованы в каче-стве аналитических срезов. Возможно задание сразу нескольких аналитических срезов (A1, A2 и т.д.). В данном случае первый срез A1 задаётся по кодам поставщиков (s), а второй A2 – по ко-дам деталей (p).
Колонка D предназначена для пометки понятий, значения которых будут использованы в каче-стве анализируемых признаков. В данном случае маркером D помечено понятие количество по-ставок (qty).
В колонках Num, Sum, Min, Max, Mid с помощью маркера Y выбирается, какие агрегирующие функции использовать – просто количество значений, их сумма, минимальное из значений, максимальное из значений, их среднее арифметическое. В данном случае подсчитывается сум-ма (Sum).
Колонка Аналитика предназначается для записи выражений аналитики.
Результаты расчёта аналитики записываются в многомерный массив (глобал). По такому мас-сиву может быть автоматически построено специальное отображение аналитики (рис. 8).


Рис. 8. Отображение с результатами аналитики

Объекты A1, A2 в отображении имеют тип массив, т.е. ссылаются на физическое дерево.
Кроме того, результаты расчёта аналитики могут быть представлены в виде перекрёстной таб-лицы (рис. 8) или в виде различных графических изображений (рис. 9).


Рис. 8. Перекрёстная таблица Рис. 9. Столбиковая диаграмма

4. Заключение
С помощью предложенного механизма физического дерева, представляющего результаты аналитической обработки и совмещающего дерево объектов и дерево экземпляров в рамках единой структуры хранения, решается задача интеграции аналитической обработки данных в предложенную модель – по такому массиву может быть автоматически построено специальное отображение с результатами расчёта аналитики.
Благодаря реализованной модели данных, а также унификации хранения, обработки и пред-ставления данных, инструмент qWORD-XML представляет собой удобную среду для быстрой и простой разработки, простого сопровождения и использования информационных систем.
С помощью инструмента qWORD-XML были разработаны Автоматизированная информацион-но-аналитическая система по проблемам инвалидности и инвалидов (АИС МСЭ) и Информаци-онно-аналитическая система органов социальной защиты населения субъекта федерации (АИС «Соцзащита»).
Литература:

1 Тимофеев Д.В. Использование платформы XML для описания расширенной реляционной модели данных RM/T. / В сб. науч. трудов Информационные технологии и системы (управление, экономика, транспорт) под ред. Истомина Е.П, Марлея В.Е., Скобелевой И.П. – СПб.: ООО «Андреевский издательский дом», 2006. – с. 137-145.
2 Кодд Э.Ф. Расширение реляционной модели для лучшего отражения семантики. http://www.osp.ru/dbms/1996/05/163.htm
3 Extensible Markup Language (XML) 1.0. http://www.w3.org/TR/REC-xml/
4 Relax NG. http://relaxng.org/
5 The Schematron. http://xml.ascc.net/resource/schematron/
6 Document Object Model (DOM). http://www.w3.org/DOM/
7 XML Path Language (XPath) Version 1.0. http://www.w3.org/TR/xpath
8 XML Path Language (XPath) 2.0. http://www.w3.org/TR/xpath20/
9 XQuery 1.0: An XML Query Language. http://www.w3.org/TR/xquery/
10 Баргесян А.А. и др. Методы и модели анализа данных: OLAP и Data Mining. – СПб.: БХВ-Петербург, 2004. – 336 с.
11 Тимофеев Д.В. Реализация логической переструктуризации в интерпретации расширенной реляционной модели данных RM/T
12 Долженков А., Тимофеев Д. Семантический инструмент построения баз данных. «Открытые системы», №01/2006

Реализация внешнего уровня для интерпретации расширенной реляционной модели RM/T

Понедельник, Декабрь 1st, 2008

Реализация внешнего уровня для интерпретации расширенной реляционной модели RM/T
Тимофеев Д.В.
Санкт-Петербургский институт информатики и автоматизации РАН
В данной работе рассматривается реализация внешнего уровня для системы, поддерживающей иерархическую модель данных с горизонтальными связями, которая является интерпретацией расширенной реляционной модели RM/T. Определяется механизм представления базы данных и взаимодействия с базой данных для пользователей системы. Разрабатывается единая инструментальная среда проектирования и использования информационных систем, которая обеспечивает унификацию хранения, представления и обработки данных.
1. Введение
В работе [1] была предложена интерпретация расширенной реляционной модели данных RM/T [2]. Согласно этой интерпретации молекулярные типы RM/T могут быть описаны структурой дерева с горизонтальными связями, дерево должно быть логическим, что позволит легко решать задачи переструктуризации дерева. Для такой структуры должна поддерживаться возможность представления горизонтальных связей в виде логических деревьев. Суррогаты должны служить для упорядочивания кортежей. Также было предложено использовать для описания этой интерпретации модели данных RM/T модель данных XML, наконец, было представлено краткое описание разработанной расширенной модели данных, основанной на модели данных RM/T, для описания которой используется модель данных XML.
В разработанной расширенной модели данных иерархическая модель данных в варианте XML наложена как вторичная поверх реляционной. Это позволяет сохранить строгость реляционной модели и привнести в неё дополнительные преимущества иерархической модели, а также использовать для описания модели как реляционную алгебру, так и языки и стандарты платформы XML: XML [3], Relax NG [4], Schematron [5], DOM [6], XPath [7, 8], XQuery [9].
Основными структурными компонентами разработанной модели данных являются понятие, объект, экземпляр объекта, код экземпляра объекта, отображение.
Объекты соответствуют типам элементов XML-документа, экземпляры объектов – отдельным элементам, а понятия – атрибутам элементов. С другой точки зрения объекты соответствуют реляционным отношениям, экземпляры объектов – кортежам отношений, а понятия – атрибутам отношений (рис. 1).


Рис 1. Структурные компоненты модели данных
Если с точки зрения XML позиция элемента это ключ естественный, то чисто с реляционной точки зрения он видится как ключ суррогатный. В разработанной модели данных этот ключ называется кодом экземпляра объекта.
Для описания связей понятий с объектами, а также связей между объектами вводится ещё одна структура – отображение. Отображение включает схему дерева объектов и дерево экземпляров. Дерево объектов соответствует схеме ХML-документа и может быть описано с помощью языка Relax NG [4], а дерево экземпляров – множеству ХML-документов, удовлетворяющих этой схеме.
Базу данных предлагается моделировать как совокупность деревьев информационных объектов с горизонтальными связями и со специфичным для каждого объекта набором понятий.
Для идентификации отображений, объектов и понятий предлагается использовать уникальные в пределах базы данных короткие коды. Относительно этих кодов определяются ограничения це-лостности и операции.
Так как задачей является построение логической структуры с возможностью переструктуризации, то и иерархические связи, и горизонтальные связи реализуются только на основе значений понятий, таким образом, все связи являются информационными.
В код экземпляра помимо первичного позиционного ключа объекта, включаются также внешние ключи, ссылающиеся на экземпляры-предки данного экземпляра (рис. 2).


Рис. 2. Реализация иерархических связей
Такой иерархический позиционный первичный ключ определяет уникальность экземпляра не только в пределах родительского экземпляра, но и в пределах любого экземпляра-предка. Используя метод редукции ключа, можно получить доступ к любому предку данного экземпляра объекта. Поэтому, несмотря на избыточность данных, такой ключ является наиболее предпочтительным, он позволяет реализовать и поддерживать иерархические связи автоматически.
Горизонтальные связи реализуются пользователем с помощью механизмов пользовательских потенциальных и внешних ключей объектов.
В модели данных предусматриваются ограничения целостности: ограничения типов и понятий, ограничения объектов и ограничения базы данных. Ограничения целостности могут быть описаны с помощью языка Schematron [5]. Благодаря выбранной структуре кодов экземпляров, правила целостности сущностей и правила ссылочной целостности для иерархических связей поддерживаются автоматически.
В модели данных предлагается поддерживать не только спецификационные операции, но и навигационные операции манипулирования данными, так как они предоставляют большую гибкость и свободу в реализации конкретных задач. Навигационные операции соответствуют низкоуровневым операциям модели DOM [6] с некоторыми расширениями. Спецификационные операции соответствуют реляционной алгебре с расширением операций на деревья объектов. Спецификационные операции могут быть описаны с помощью языка XQuery [9].
В работе [10] были предложены механизмы для логической переструктуризации дерева объектов – ссылочные и виртуальные объекты. Ссылочные объекты ссылаются на экземпляры объектов, реально существующие в базе данных. Виртуальные объекты позволяют создавать виртуальные деревья объектов. С помощью предложенных механизмов реализуются операции произведения и соединения без создания дополнительных структур хранения, решается задача представления горизонтальных связей как логических иерархических, задача инвертирования иерархии.
В работе [11] был предложен механизм интеграции аналитической обработки данных в разработанную модель данных. Согласно этому механизму результатом аналитической обработки становится физическое дерево, в котором уровни представляют собой аналитические срезы, а значения – анализируемые признаки – и в котором совмещаются дерево объектов и дерево экземпляров в рамках единой структуры хранения. В результате по такому физическому дереву может быть автоматически построено специальное отображение с результатами расчёта аналитики.
В работе [12] был предложена реализация физического уровня для системы, поддерживающей разработанную модель данных. В качестве средства для реализации физического уровня предлагается использовать M-системы. Для быстрого чтения экземпляров в последовательно-сти иерархического обхода предлагается в качестве основной структуры хранения использовать кластерный индекс кодов экземпляров. В кластерном индексе экземпляры каждого объекта хранятся в порядке кодов экземпляров вместе с данными экземпляров. Для быстрого поиска требуемых экземпляров реализуются некластерные индексы, которые ссылаются на коды эк-земпляров кластерного индекса. Для устранения избыточности, свойственной иерархической организации данных, на физическом уровне предлагается выполнять кодирование слов струк-турированных значений понятий суррогатными кодами.
На основании предложенного подхода разработан инструмент для построения и использования информационных систем qWORD-XML [13].
В данной работе рассматривается реализация внешнего уровня инструмента qWORD-XML. Определяется механизм представления базы данных и взаимодействия с базой данных для пользователей системы.
Современные промышленные СУБД имеют набор интерфейсов к внешним инструментам проектирования и разработки приложений или снабжаются инструментальными средствами собственного производства. В общем случае имеется набор различных инструментов: соб-ственно инструментарий СУБД, среда проектирования базы данных, среда разработки при-ложений, инструмент для поиска и аналитической обработки данных, генератор отчётов. Соответственно, для построения и использования информационной системы необходимо одинаково хорошо владеть всеми инструментальными средствами, которые могут сильно разниться друг с другом.
Поэтому задачей является разработка системы, которая совмещает эти инструменты в рамках единого универсального визуального инструмента. Это позволит значительно облегчить работу пользователей, ускорить разработку информационных систем и упростить их сопровождение.
2. Взаимодействие клиента и сервера
Для решения поставленной задачи в данной работе предлагается перенести всё программирование информационной системы – взаимодействие с базой данных, описание логики работы приложения, реализацию пользовательского интерфейса – на сторону сервера и осуществлять на языке M.
Собственно инструментальную среду qWORD-XML, названную универсальным браузером, предлагается реализовать на Delphi как клиентское приложение к M-серверу. Управление клиентской частью предлагается осуществлять в реальном времени по командам сервера. Управление клиентской частью включает в себя создание объектов – экземпляров классов Delphi, установку их свойств и вызов их методов в реальном времени по командам сервера. Эти классы являются потомками визуальных (соответствующих видимым объектам) и невизуаль-ных классов Delphi.
Для взаимодействия с клиентской частью на сервере создаётся системный класс qARM, который содержит как методы управления клиентской частью, так и методы-обработчики событий клиента.
Управление клиентской частью реализуется с помощью следующих методов класса qARM (табл. 1).
Табл. 1. Управление клиентской частью
Действие Вызов метода на сервере
Создание объекта класса Delphi D qARM.wC(<класс>,<имя объекта>,<параметры>)
Вызов метода объекта D qARM.wM(<имя объекта>,<имя метода>,<параметры>)
Присвоение значения свойству объекта D qARM.wP(<имя объекта>,<имя свойства>,<значение>)
Предлагается следующая схема взаимодействия клиентской части и серверной части (здесь предполагается, что вся инициализация уже выполнена и система находится в состоянии ожи-дания действий пользователя) (рис. 3).


Рис. 3. Схема взаимодействия клиента и сервера
Пользователь производит некоторое действие, требующее реакции системы (нажатие кнопки мыши, клавиши и др.) Происходит событие (1), обработчик события клиентской программы вызывает (2) соответствующий метод-обработчик из класса qARM сервера и передает ему не-обходимые параметры, например, имя метода, который необходимо выполнить по данному действию пользователя. Обращение к серверу всегда является модальным для клиента, т.е. кли-ентское приложение ожидает завершения выполнения метода на сервере, прежде чем сможет продолжить выполнение. Благодаря этому уменьшается количество пересылок между клиентом и сервером и увеличивается скорость работы.
В это время на сервере вызванный метод (3) производит некоторые действия и может обра-щаться к методам wC, wM, wP. Эти методы не вызывают никаких действий на клиенте (он про-стаивает в ожидании), однако при этом формируется программа для клиента – запись последо-вательности действий, которые необходимо осуществить на клиенте (4). По окончании выпол-нения серверного метода работа клиентского приложения продолжается, оно считывает сфор-мированную программу (5) и последовательно её исполняет (6), создавая объекты, присваивая значения их свойствам и вызывая их методы. Пока клиент занят обработкой программы, все действия пользователя ставятся в очередь для последующей обработки.
При программировании на стороне сервера вызываются методы работы с базой данных и мето-ды клиентской части (методы объектов Delphi). Весь вид приложения определяется сервером и создается практически «с нуля» в процессе работы, а универсальный браузер представляет собой универсальное клиентское приложение ко всем построенным в qWORD-XML базам данных.
3. Универсальный браузер
В универсальном браузере всё взаимодействие с информационной системой предлагается реализовать через отображения (экранные формы). Главным системным отображением яв-ляется отображение Проводник (рис. 4).


Рис. 4. Отображение Проводник
Любое отображение состоит в общем случае из дерева объектов (левая часть окна), дерева экземпляров объектов (правая часть окна) и панелей инструментов.
Верхняя панель инструментов содержит кнопки непосредственного выполнения действий и кнопки вызовов меню. Здесь в частности присутствуют кнопки ввода и удаления экземпляров, поиска, расчёта аналитики, построения диаграммы, пункты меню печать отображения, вызов аналитического отображения. Левая панель содержит кнопки навигации по дереву экземпляров, а также кнопки управления окнами. Панели инструментов могут частично или полностью от-сутствовать – режим их вывода задается в описании отображения.
В левой части отображения располагается дерево объектов. Дерево объектов состоит из не-скольких колонок. Колонка 0 содержит собственно дерево объектов текущего отображения с понятиями этих объектов. Колонки 1 и далее предназначены для задания условий поиска и ана-литической обработки.
В дереве объектов системного отображения Проводник присутствуют следующие системные объекты:
%Отображение – содержит описания всех отображений (системных отображений инструмента и пользовательских отображений конкретной базы данных);
%Запрос – содержит описание всех созданных запросов;
%Пользователь – содержит учётные записи всех пользователей базы данных;
%Объект – содержит описание всех объектов (системных и пользовательских);
%Понятие – содержит описание всех понятий (системных и пользовательских);
%База содержит общее описание и настройки базы данных.
Конкретные отображения, запросы, пользователи, объекты, понятия являются экземплярами этих системных объектов и выводятся в дереве экземпляров. Дерево экземпляров располагается в правой части отображения. Состояние дерева экземпляров меняется при изменении состояния дерева объектов. Дерево экземпляров представляет собой дерево множеств экземпляров, соот-ветствующее текущему состоянию дерева объектов.
Проектирование структуры базы и построение приложений
Редактирование отображений предлагается производить в специальном режиме. Экран редак-тирования представляет собой интерпретацию отображения как дерева-таблицы (рис. 5) и по-зволяет описывать как структуру дерева объектов, так и внешний вид дерева экземпляров.


Рис. 5. Экран редактирования отображения
В столбце Объекты выстраивается дерево объектов (иерархические связи между объектами). В колонках 0 и далее задаются понятия объектов (связи понятий и объектов) и описание внешнего вида дерева экземпляров.
Дерево объектов выстраивается последовательно, начиная от вершины. Добавление объектов производится через контекстное меню. Объект выбирается из множества заранее определённых объектов. Можно вставить объект сразу с набором его понятий или поддерево объекта с поня-тиями. При добавлении объекта порождается нулевая строка объекта и нулевая ячейка в этой строке.
Описание дерева экземпляров создаётся путём добавления строк и колонок к дереву-таблице. Описание экземпляра объекта может занимать несколько строк и колонок дерева-таблицы. Объекты нижнего уровня могут быть встроены в произвольные строки объектов верхнего уров-ня. В ячейках дерева экземпляров могут выводиться не только понятия, но и константы, и вы-ражения.
Описание отображения создаётся в результате визуального проектирования и представляет собой такой же хранимый элемент базы данных как объекты и понятия.
При выходе из редактирования отображения описание отображения автоматически записывает-ся в базу данных, также автоматически заполняются свойства описаний объектов Понятия, По-томки и Объектная ссылка. Таким образом, с использованием отображений строится схема ба-зы.
Проектирование базы данных в qWORD-XML предлагается начинать c построения отображе-ния или нескольких отображений, в которых объекты располагаются соответственно модели-руемой иерархии. Вместе эти отображения будут определять схему базы данных как совокуп-ность деревьев.
Горизонтальные связи в предложенной модели реализуются с помощью пользовательских по-тенциальных и внешних ключей. Горизонтальные связи могут быть представлены как иерархи-ческие с помощью дополнительных отображений с использованием ссылочных и виртуальных объектов.
Таким образом, в данной работе отображение предлагается использовать как средство описания структуры базы. Экранное представление базы данных может быть создано в виде отобра-жения, описывающего общую схему базы данных или нескольких отображений, описы-вающих части общей схемы (рис. 6). Такой вариант удобен для аналитических задач.


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


7. Стартовое отображение приложения
Различных экранных представлений базы может быть создано сколько угодно. За счёт того, что на экран выводятся только описанные в отображении объекты и понятия, можно создавать ра-бочие места для разных типов пользователей с различными правами доступа к информации в базе.
Генератор печатных форм
Отображение предлагается интерпретировать как выходную печатную форму. В основе процес-са генерации печатных форм лежит XML-ориентированный поход системы. На основании те-кущего состояния дерева объектов и дерева экземпляров формируется XML-документ, содер-жащий данные для печати. На основании внешнего вида отображения формируется XSLT-документ. XSLT-документ представляет собой набор инструкций, описывающих преобразова-ние структуры входящего XML-документа в выходящий документ. XML-документ вместе с XSLT-документом передается XSLT-процессору. XSLT-процессор, применяя правила преобра-зования, формирует выходящий документ, который затем открывается в заданном приемнике (в качестве приёмника могут выступать Microsoft Internet Explorer, Microsoft Word, Microsoft Excel). Выходящий документ по своей структуре является HTML-документом. То есть, XSLT-документ описывает преобразование XML-документ в HTML-документ. Однако для получения необходимого форматирования выходящего документа в приёмнике, в HTML-документ долж-ны присутствовать специфичные для этого приёмника стили (например, для вывода колонтиту-лов, разрывов страниц, расстановки переносов и т.д.).


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


Рис. 9. Условия поиска на значения
По результат поиска строится перечень релевантных – перечень экземпляров объектов, удовле-творяющих условиям поиска. При этом в дерево экземпляров выводятся только те экземпляры объектов, которые присутствуют в перечне релевантных.
Условия поиска на значения понятий могут содержать слово значения понятия, шаблон слова значения понятия, диапазон слова значения понятия, произвольное выражение, все эти условия могут группироваться по И, по ИЛИ и по НЕ.
Аналитическая обработка данных
Аналитическую обработку также предлагается выполнять в рамках отображения (рис. 10). Пе-ред выполнением аналитической обработки может быть организован предварительный поиск данных.


Рис. 10. Аналитический запрос
Для примера, рассмотрим запрос, в котором необходимо:
определить общее количество поставок по поставщикам и деталям;
определить общее количество поставок по поставщикам;
определить общее количество поставок.
Колонка A предназначена для пометки понятий, значения которых будут использованы в каче-стве аналитических срезов. Возможно задание сразу нескольких аналитических срезов (A1, A2 и т.д.). В данном случае первый срез A1 задаётся по кодам поставщиков (s), а второй A2 – по ко-дам деталей (p).
Колонка D предназначена для пометки понятий, значения которых будут использованы в каче-стве анализируемых признаков. В данном случае маркером D помечено понятие количество по-ставок (qty).
В колонках Num, Sum, Min, Max, Mid с помощью маркера Y выбирается, какие агрегирующие функции использовать – просто количество значений, их сумма, минимальное из значений, максимальное из значений, их среднее арифметическое. В данном случае подсчитывается сум-ма (Sum).
Колонка Аналитика предназначается для описания преобразования значений из Аi и D до их агрегирования.
Результаты расчёта аналитики записываются в многомерный массив (глобал). По такому мас-сиву может быть автоматически построено специальное отображение аналитики (рис. 11).


Рис. 11. Отображение с результатами аналитики
Объекты A1, A2 в отображении имеют тип массив, т.е. ссылаются на физическое дерево.
Кроме того, результаты расчёта аналитики могут быть представлены в виде перекрёстной таб-лицы (рис. 12) или в виде различных графических изображений (рис. 13).


Рис. 12. Перекрёстная таблица Рис. 13. Столбиковая диаграмма
4. Заключение
На внешнем уровне инструмент qWORD-XML реализуется как клиентское приложение к M-серверу.
Через предложенный механизм отображений обеспечивает все необходимые средства для работы с информационной системой:
1. Отображение представляет собой инструмент для визуального проектирования структу-ры базы данных, а также средство представления этой структуры и данных, соответствую-щих этой структуре. Кроме того, в рамках отображения с помощью виртуальных и ссылоч-ных объектов предоставляется возможность логической переструктуризации базы.
2. Отображение представляет собой инструмент для визуального построения приложений к спроектированной базе данных, а также собственно экранную форму приложения.
3. Отображение представляет собой визуальное средство для проектирования внешнего ви-да выходной печатной формы.
4. Отображение представляет собой визуальное средство для поиска данных и для пред-ставления результатов поиска.
5. Отображение предоставляет визуальное средство для аналитической обработки данных и для предоставления результатов обработки.
Таким образом, в рамках отображения объединяются собственно данные, их структура, представление и обработка. Описание отображения включает в себя описание схемы дерева объектов и описание внешнего вида дерева экземпляров вместе с вызовами действий по си-туациям. Описание отображения представляет собой такой же хранимый элемент базы дан-ных как объекты и понятия и создаётся в результате визуального проектирования.
Всё программирование информационной системы – взаимодействие с базой данных, описание логики работы приложения, реализация пользовательского интерфейса – осуществляется на языке M на стороне сервера. При этом вызываются методы работы с базой данных и методы клиентской части (методы объектов Delphi). Собственно программирование информационной системы в qWORD-XML сводится к построению отображений и определению действий по ситуациям, а универсальный браузер представляет собой универсальное клиентское при-ложение ко всем построенным в qWORD-XML информационным системам.
Благодаря реализованной модели данных, унификации хранения, обработки и представления данных, унификации программирования, инструмент qWORD-XML представляет собой удоб-ную среду для быстрой и простой разработки, простого сопровождения и использования ин-формационных систем.
С помощью инструмента qWORD-XML были разработаны Автоматизированная информацион-но-аналитическая система по проблемам инвалидности и инвалидов (АИС МСЭ) и Информаци-онно-аналитическая система органов социальной защиты населения субъекта федерации (АИС «Соцзащита»).
Литература
1 Тимофеев Д.В. Использование платформы XML для описания расширенной реляционной модели данных RM/T.
2 Кодд Э.Ф. Расширение реляционной модели для лучшего отражения семантики. http://www.osp.ru/dbms/1996/05/163.htm
3 Extensible Markup Language (XML) 1.0. http://www.w3.org/TR/REC-xml/
4 Relax NG. http://relaxng.org/
5 The Schematron. http://xml.ascc.net/resource/schematron/
6 Document Object Model (DOM). http://www.w3.org/DOM/
7 XML Path Language (XPath) Version 1.0. http://www.w3.org/TR/xpath
8 XML Path Language (XPath) 2.0. http://www.w3.org/TR/xpath20/
9 XQuery 1.0: An XML Query Language. http://www.w3.org/TR/xquery/
10 Тимофеев Д.В. Реализация логической переструктуризации в интерпретации расширенной реляционной модели данных RM/T
11 Тимофеев Д.В. Аналитическая обработка данных в интерпретации расширенной реляцион-ной модели RM/T.
12 Тимофеев Д.В. Реализация физического уровня для интерпретации расширенной реляцион-ной модели RM/T.
13 Долженков А., Тимофеев Д. Семантический инструмент построения баз данных. «Открытые системы», №01/2006

Расширение реляционной технологии для создания информационных систем на основе языков разметки

Среда, Ноябрь 19th, 2008

УДК 004.65

Тимофеев Д.В.
Санкт-Петербургский институт информатики и автоматизации РАН
В статье предлагается инструментальное средство для построения информационных систем qWORD-XML, главной целью создания которого явилось повышение удобства построения, развития и эксплуатации информационных систем. Для этого вводится расширенная модель данных, позволяющая «удерживать больше смысла данных», а также разрабатывается единая инструментальная среда проектирования и использования информационных систем, которая обеспечивает унификацию хранения, представления и обработки данных.
1. Введение

Главной целью совершенствования процесса разработки и эксплуатации информационных систем является повышение удобства их построения, развития и использования. Для этого необходима модель данных, позволяющая «удерживать больше смысла данных», а также единая инструментальная среда проектирования и использования информационных систем, которая обеспечивает унификацию хранения, представления и обработки данных. Это определяет основные две задачи данного исследования.
Большая часть данных, возникающих в ходе деятельности предприятия, представлена в виде документов. Манипулирование этими данными называется документооборотом. С точки зрения манипулирования данными, все аспекты деятельности либо являются документооборотом, либо могут быть формально к нему сведены.
В основе информационной системы лежит система баз данных. Система баз данных предоставляет предприятию средства централизованного управления его данными. На сегодняшний день доминирующее положение занимают реляционные СУБД, они предоставляют удобный способ хранения информации, представленной в виде таблиц. Структура данных большинства реальных документов может быть представлена как произвольное иерархическое дерево с горизонтальными связями. Поэтому документы хранятся либо полностью в одной ячейке таблицы реляционной базы, либо разбиваются на множество таблиц, некоторые таблицы, полученные из разных документов, объединяются. В реляционной базе имеем дело с другими документами, поэтому алгоритм обработки реального документа невозможно положить в основу алгоритма программного кода хранимой процедуры. Реальные документы опять появляются только на уровне приложения. Здесь, по сути, имеем дело не с отображением, а с перепроектированием документов, и, соответственно, документооборота. Соответственно появляются модель предметной области на уровне базы данных и модель предметной области на уровне приложений, между которыми необходимо реализовывать отображение. В результате усложняется построение информационной системы, а если предметная область является динамической, то также развитие и сопровождение информационной системы. В этой связи наиболее перспективным является прямая реализация СУБД, основанной на расширенной модели данных, в большей степени соответствующей семантике предметной области. При этом разработка информационных систем станет в большей степени описательной, декларативной.
Первой задачей является разработка расширенной модели данных, несущей большую смысловую нагрузку, чем базовая реляционная модель, но при этом являющейся естественным расширением реляционной модели.
В качестве основы такой модели в данной работе предлагается использовать расширенную реляционную модель RM/T [1]. Эта модель была предложена Коддом с целью расширения семантических аспектов реляционной модели. В RM/T вводятся различные семантические абстракции (декартова агрегация, обобщение, агрегация покрытия, предшествование событий), а также формальные объекты, правила целостности и операторы. Однако механизм реализации расширений в RM/T является низкоуровневым, что делает модель более мощной и гибкой, но вместе с тем более сложной и ориентированной в первую очередь на программистов, а не на пользователей.
Для описания молекулярных типов RM/T предлагается введение молекулярной структуры – дерева с горизонтальными связями – поверх атомарной структуры – n-мерного отношения. Дерево должно быть логическим, что позволит легко решать задачи переструризации дерева. Также должна поддерживаться возможность представления горизонтальных связей в виде логических деревьев. Логико-математический аппарат иерархической базы данных с горизонтальными связями, в общем случае, существенно сложнее, чем реляционных – последние лишь частный случай первых. Однако с созданием и развитием платформы XML появилась возможность формального описания иерархической модели с горизонтальными связями.
На основе языков платформы XML может быть построена модель данных. Структурой данных этой модели является дерево элементов с горизонтальными связями, задаваемое базовой спецификацией XML [2], языками описания схем Relax NG [3], Schematron [4], элементы этого дерева упорядочены. Ограничения целостности задаются с помощью языков Relax NG, Schematron. Операции осуществляются с использованием DOM [5], XPath [6, 7] и XQuery [8]. И эта модель данных позволяет описать предложенную интерпретацию модели RM/T.
Современные промышленные СУБД имеют набор интерфейсов к внешним инструментам проектирования и разработки приложений или снабжаются инструментальными средствами собственного производства. В общем случае имеется набор различных инструментальных средств: собственно инструментарий СУБД, среда проектирования базы данных, среда разработки приложений, инструмент для поиска и аналитической обработки данных, генератор отчётов.
Второй задачей является разработка системы, которая совмещает эти инструментальные средства в рамках единой универсальной визуальной среды проектирования и использования информационных систем. Это позволит значительно облегчить работу пользователей, ускорить разработку информационных систем и упростить их сопровождение.

2. Модель данных qWORD-XML
В рамках решения первой из поставленных задач необходимо осуществить наложение иерархической модели данных в варианте XML как вторичной поверх реляционной. Это позволит сохранить строгость реляционной модели и привнести в неё дополнительные преимущества иерархической модели [9], а также использовать для описания модели qWORD-XML как реляционную алгебру, так и языки платформы XML: XML, Relax NG, Schematron, DOM, XPath, XQuery.
Основными структурными компонентами модели данных qWORD-XML являются понятие, объект, экземпляр объекта, код экземпляра объекта, отображение.
Объекты соответствуют типам элементов XML-документа, экземпляры объектов – отдельным элементам, а понятия – атрибутам элементов. С другой точки зрения объекты соответствуют реляционным отношениям, экземпляры объектов – кортежам отношений, а понятия – атрибутам отношений (рис. 1). Если с точки зрения XML позиция элемента это ключ естественный, то чисто с реляционной точки зрения он видится как ключ суррогатный. В модели данных qWORD-XML этот ключ называется кодом экземпляра объекта. Для описания связей понятий с объектами, а также связей между объектами вводится ещё одна структура – отображение. Отображение включает схему дерева объектов и дерево экземпляров. Дерево объектов соответствует схеме ХML-документа и может быть описано с помощью языка Relax NG [3], а дерево экземпляров – множеству ХML-документов, удовлетворяющих этой схеме. Базу данных предлагается моделировать как совокупность деревьев информационных объектов с горизонтальными связями и со специфичным для каждого объекта набором понятий.


Рис 1. Структурные компоненты модели данных qWORD-XML
Так как задачей является построение логической структуры с возможностью переструктуризации, то и иерархические связи, и горизонтальные связи реализуются только на основе значений понятий, таким образом, все связи являются информационными.
В код экземпляра помимо первичного позиционного ключа объекта, включаются также внешние ключи, ссылающиеся на экземпляры-предки данного экземпляра (рис. 2). Такой иерархический позиционный первичный ключ определяет уникальность экземпляра не только в пределах родительского экземпляра, но и в пределах любого экземпляра-предка. Используя метод редукции ключа, можно получить доступ к любому предку данного экземпляра объекта. Поэтому, несмотря на избыточность данных, такой ключ является наиболее предпочтительным, он позволяет реализовать и поддерживать иерархические связи автоматически.


Рис. 2. Структура иерархических ключей

Горизонтальные связи могут быть реализованы пользователем с помощью механизмов пользовательских потенциальных и внешних ключей объектов.
Значения понятий могут быть структурированными и неструктурированными. Под структурированным значением понимается последовательность слов, разделённых пробелами. Неструктурированное значение – это многострочный текст или последовательность байтов, которая может интерпретироваться как изображение, звук, видео.
Иерархической организации данных свойственно дублирование информации и соответственно избыточность данных. Такое дублирование является естественным для человека, так в процессе документооборота часто данные многократно переносятся по цепочке от одного документа к другому, что вполне естественно и должно адекватно отражаться в модели данных. Дублирование информации позволяет отказаться от реализации горизонтальных связей между отдельными деревьями и непосредственно использовать значения. Вопрос о минимизации количества хранимой информации – это вопрос физического уровня, а не уровня модели.
В модели данных qWORD-XML предусматриваются ограничения целостности: ограничения типов и понятий, ограничения объектов и ограничения базы данных. Ограничения целостности могут быть описаны с помощью языка Schematron [4]. Благодаря выбранной структуре кодов экземпляров, правила целостности сущностей и правила ссылочной целостности для иерархических связей поддерживаются автоматически.
В модели данных предлагается поддерживать как навигационные операции манипулирования данными, так и спецификационные, так как навигационные операции предоставляют большую гибкость и свободу в реализации конкретных задач. Кроме того, в системах изначально ориентированных только на спецификационные операции, навигационные операции появляются на уровне приложений, например, в виде курсоров. Навигационные операции соответствуют низкоуровневым операциям модели DOM [5] с некоторыми расширениями. Спецификационные операции соответствуют реляционной алгебре с расширением операций на деревья объектов. Спецификационные операции могут быть описаны с помощью языка XQuery [8].
На основании предложенной структуры кодов экземпляров легко решается задача инвертирования иерархии, реализуется операция проекции общей схемы базы данных по объектам.
Для логической переструктуризации дерева предлагаются механизмы ссылочных и виртуальных объектов. Ссылочные объекты ссылаются на экземпляры объектов, реально существующие в базе данных, при этом операции манипулирования экземплярами ссылочных объектов поддерживаются системой. Виртуальные объекты позволяют создавать виртуальные деревья объектов. Операции манипулирования экземплярами должны реализовываться пользователем. С помощью механизмов ссылочных и виртуальных объектов решается задача представления горизонтальных связей как логических иерархических, реализуются операции произведения и соединения.
Модель данных qWORD-XML основывается на базовой реляционной модели данных и модели данных XML и является функциональной полной. Она позволяет манипулировать логическими деревьями с горизонтальными связями, предоставляет средства логической переструктуризации дерева с возможностью представления горизонтальных связей в виде логических деревьев и соответствует модели данных RM/T. Модель также обладает свойством самоописания, что позволяет использовать одни те же операции для манипулирования как данными, так и метаданными.
3. Физический уровень

На физическом уровне qWORD-XML реализуется как надстройка над M-системой [10, 11, 12]. M-системы с одной стороны предоставляют низкоуровневый интерфейс к структурам хранения, что позволяет получить свободу и гибкость в принятии проектных решение, а с другой обладают развитыми возможностями СУБД, что позволяет значительно упростить разработку. Вместе с тем следует отметить, что M – это, прежде всего, эффективное средство для разработки СУБД, а не собственно СУБД.
Главным достоинством М-систем является эффективный механизм управления внешней памятью в виде B*-деревьев, которые на логическом уровне представляются через глобалы. Глобал – это хранимый на диске рассортированный по строковым индексам резреженный массив произвольной размерности.
Основными используемыми в данной работе преимуществами глобалов являются:
• Сортировка элементов глобалов в момент записи, представляемая на логическом уровне (на уровне глобалов), что непосредственно позволяет использовать глобалы для построения индексов.
• Сжатие ключей, что позволяет представлять логически связанные структуры хранения совместно, при этом логическая избыточность на физическом уровне устраняется.
С помощью глобалов реализуются структуры хранения инструмента qWORD-XML. Так как элементы XML-документы логически упорядочены по позициям, то для быстрого чтения экземпляров в последовательности иерархического обхода, необходимо обеспечить их хранение в непосредственной близости друг от друга. Для этого в данной работе предлагается хранить данные в кластерном индексе кодов экземпляров в порядке кодов экземпляров. Таким образом, код экземпляра на уровне хранения становится ключом кластерного индекса. Для быстрого поиска требуемых экземпляров предлагается использовать некластерные индексы, ссылающиеся на кластерный индекс.
Для устранения избыточности, свойственной иерархической организации данных, на физическом уровне предлагается выполнять кодирование слов структурированных значений понятий суррогатными кодами. На основании предложенного подхода реализуются кластерный индекс слов значений, ключом которого является суррогатный код слова значения, и некластерный индекс слов значений.

4. Универсальная инструментальная среда
Для решения второй поставленной задачи в данной работе предлагается перенести всё программирование информационной системы – взаимодействие с базой данных, описание логики работы приложения, реализацию пользовательского интерфейса – на сторону сервера и осуществлять на языке M. При этом весь вид приложения будет определяться сервером, и создаваться практически «с нуля» в процессе работы с системой.
Инструментальная среда qWORD-XML называется универсальным браузером, и реализуется как клиентское приложение к M-серверу. В универсальном браузере всё взаимодействие пользователя с информационной системой предлагается реализовать через экранные формы, которые называются отображениями. Отображение состоит в общем случае из дерева объектов, дерева экземпляров объектов и панелей инструментов (рис. 3).


Рис. 3. Экранная форма универсального браузера

Через механизм отображений обеспечиваются все необходимые средства для работы с информационной системой. Отображение представляет собой:
1. Инструментую среду для визуального проектирования структуры базы данных, а также средство представления этой структуры и данных, соответствующих этой структуре.
2. Инструментальную среду для визуального построения приложений к спроектированной базе данных, а также собственно экранную форму приложения.
3. Визуальное средство для проектирования внешнего вида выходной печатной формы.
4. Визуальное средство для поиска данных и для представления результатов поиска.
5. Визуальное средство для аналитической обработки данных и для предоставления результатов обработки. Дополнительно реализована возможность предоставления результатов аналитической обработки в виде перекрёстной таблицы или в виде различных диаграмм с помощью встроенного в универсальный браузер компонента.
Таким образом, в рамках отображения объединяются собственно данные, их структура, представление и обработка. Описание отображения представляет собой такой же хранимый элемент базы данных как объекты и понятия. Оно создаётся в результате визуального проектирования и включает в себя описание схемы дерева объектов, описание внешнего вида дерева экземпляров вместе с вызовами действий по ситуациям.
Собственно программирование информационной системы в qWORD-XML сводится к построению отображений и определению действий по ситуациям, а универсальный браузер представляет собой универсальное клиентское приложение ко всем построенным в qWORD-XML информационным системам.
Заключение

Благодаря реализованной модели данных, а также унификации хранения, обработки и представления данных, инструмент qWORD-XML представляет собой удобную среду для быстрой и простой разработки, простого сопровождения и использования информационных систем.
С помощью инструмента qWORD-XML были разработаны Автоматизированная информационно-аналитическая система по проблемам инвалидности и инвалидов (АИС МСЭ) и Информационно-аналитическая система органов социальной защиты населения субъекта федерации (АИС «Соцзащита»).
В целом, применение инструмента qWORD-XML оказывается наиболее эффективным для реализации информационных проектов, связанных с использованием значительных по объему массивов данных, например, о населении, при этом ведение базы данных осуществляется на основе работы с привычными для пользователя формами документов.

Список литературы:

1 Кодд Э.Ф. Расширение реляционной модели для лучшего отражения семантики. http://www.osp.ru/dbms/1996/05/163.htm
2 Extensible Markup Language (XML) 1.0. http://www.w3.org/TR/REC-xml/
3 Relax NG. http://relaxng.org/
4 The Schematron. http://xml.ascc.net/resource/schematron/
5 Document Object Model (DOM). http://www.w3.org/DOM/
6 XML Path Language (XPath) Version 1.0. http://www.w3.org/TR/xpath
7 XML Path Language (XPath) 2.0. http://www.w3.org/TR/xpath20/
8 XQuery 1.0: An XML Query Language. http://www.w3.org/TR/xquery/
9 Веселов В.В., Долженков А.Н. Опыт построения XML-СУБД. – «Открытые Системы», 2002, №06.
10 Гессе С., Кирстен В. Введение в язык программирования М. – СПб: АОЗТ «СП. АРМ», 1996 – 280с.
11 Кирстен В. От ANS MUMPS к ISO M. – СПб: СП.АРМ, 1995 – 277с.
12 Кирстен В и др. Постреляционная СУБД Cache 5: объектно-ориентированная разработка приложений. 2-е изд., перераб. и дополн. – М.: ООО «Бином-Пресс», 2005. – 416 с.

Реализация логической переструктуризации в интерпретации расширенной реляционной модели данных RM/T

Среда, Ноябрь 19th, 2008
Тимофеев Д.В.
Санкт-Петербургский институт информатики и автоматизации РАН
В данной работе рассматривается реализация реляционных операций произведения и соедине-ния без создания дополнительных структур хранения и использование этих операций для логи-ческой переструктуризации иерархической структуры с горизонтальными связями – представ-ления горизонтальных связей как логических иерархических, инвертирования иерархии – в мо-дели данных, которая является интерпретацией расширенной реляционной модели данных RM/T.
1. Введение
В работе [1] была предложена интерпретация расширенной реляционной модели данных RM/T [2]. Согласно этой интерпретации молекулярные типы RM/T могут быть описаны структурой дерева с горизонтальными связями, дерево должно быть логическим, что позволит легко решать задачи переструктуризации дерева. Для такой структуры должна поддерживаться возможность представления горизонтальных связей в виде логических деревьев. Суррогаты RM/T должны служить для упорядочивания кортежей. Также было предложено использовать для описания этой интерпретации модели данных RM/T модель данных XML, наконец, было представлено краткое описание разработанной расширенной модели данных, основанной на модели данных RM/T, для описания которой используется модель данных XML.
В разработанной расширенной модели данных иерархическая модель данных в варианте XML накладывается как вторичная поверх реляционной. Это позволяет сохранить строгость реляционной модели и привнести в неё дополнительные преимущества иерархической модели, а также использовать для описания модели как реляционную алгебру, так и языки и стандарты платформы XML: XML [3], Relax NG [4], Schematron [5], DOM [6], XPath [7, 8], XQuery [9].
Основными структурными компонентами разработанной модели данных являются понятие, объект, экземпляр объекта, код экземпляра объекта, отображение.
Объекты соответствуют типам элементов XML-документа, экземпляры объектов – отдельным элементам, а понятия – атрибутам элементов. С другой точки зрения объекты соответствуют реляционным отношениям, экземпляры объектов – кортежам отношений, а понятия – атрибутам отношений (рис. 1).


Рис 1. Структурные компоненты модели данных

Если с точки зрения XML позиция элемента это ключ естественный, то чисто с реляционной точки зрения он видится как ключ суррогатный. В разработанной модели данных этот ключ называется кодом экземпляра объекта.
Для описания связей понятий с объектами, а также связей между объектами вводится ещё одна структура – отображение. Отображение включает схему дерева объектов и дерево экземпляров. Дерево объектов соответствует схеме ХML-документа и может быть описано с помощью языка Relax NG [4], а дерево экземпляров – множеству ХML-документов, удовлетворяющих этой схеме.
Базу данных предлагается моделировать как совокупность деревьев информационных объектов с горизонтальными связями и со специфичным для каждого объекта набором понятий.
Для идентификации отображений, объектов и понятий предлагается использовать уникальные в пределах базы данных короткие коды. Относительно этих кодов определяются ограничения це-лостности и операции.
Так как задачей является построение логической структуры с возможностью переструктуризации, то и иерархические связи, и горизонтальные связи реализуются только на основе значений понятий, таким образом, все связи являются информационными.
В код экземпляра помимо первичного позиционного ключа объекта, включаются также внешние ключи, ссылающиеся на экземпляры-предки данного экземпляра (рис. 2).


Рис. 2. Реализация иерархических связей

Используемый иерархический позиционный первичный ключ определяет уникальность экземпляра не только в пределах родительского экземпляра, но и в пределах любого экземпляра-предка. Используя метод редукции ключа, можно получить доступ к любому предку данного экземпляра объекта. Поэтому, несмотря на избыточность данных, данный ключ является наиболее предпочтительным, так как позволяет реализовать и поддерживать иерархические связи автоматически.
Горизонтальные связи реализуются пользователем с помощью механизмов пользовательских потенциальных и внешних ключей объектов.
В модели данных предусматриваются ограничения целостности: ограничения типов и понятий, ограничения объектов и ограничения базы данных. Ограничения целостности могут быть описаны с помощью языка Schematron [5]. Благодаря выбранной структуре кодов экземпляров, правила целостности сущностей и правила ссылочной целостности для иерархических связей поддерживаются автоматически.
В модели данных предлагается поддерживать не только спецификационные операции, но и навигационные операции манипулирования данными, так как они предоставляют большую гибкость и свободу в реализации конкретных задач. Навигационные операции соответствуют низкоуровневым операциям модели DOM [6] с некоторыми расширениями. Спецификационные операции соответствуют реляционной алгебре с расширением операций на деревья объектов. Спецификационные операции могут быть описаны с помощью языка XQuery [9].
В данной работе рассматриваются задачи логической переструктуризации дерева с горизонтальными связями в разработанной модели данных – задача представления горизонтальных связей в виде логических иерархических, задача инвертирования иерархии.
В реляционной алгебре выделяются две операции, связанные с созданием новых структур – это операции произведения и соединения. Результатом этих операций в общем случае является не-которое вычисляемое виртуальное отношение. Однако если на уровне модели такое отношение является виртуальным, то на физическом уровне всё равно создаются кортежи этого виртуаль-ного отношения.
Конкретной задачей работы является реализация операций произведения и соединения без соз-дания дополнительных физических записей только на основе хранимых объектов и экземпля-ров. Для построения логических структур, не соответствующих структуре хранимого дерева, в данной работе предлагаются механизмы ссылочных и виртуальных объектов.
В разработанной модели главной структурой является дерево объектов, соответственно, опера-ции реляционной алгебры, выполняющиеся над отношениями, распространяются на деревья объектов. Спецификационные операции, в том числе операции произведения и соединения, предлагается выполнять в рамках отображения.
2. Произведение
В реляционной алгебре операция произведения возвращает отношение, кортежи которого яв-ляются сцеплением кортежей первого и второго операндов.
Операцию произведения с помощью реляционной алгебры можно записать так: A TIMES B
Ссылочные объекты являются механизмом переструктуризации хранимого дерева, они ссыла-ются только на экземпляры, реально существующие в базе данных. В общем случае при описа-нии ссылочного объекта необходимо задать выражение для получения следующего кода экзем-пляра относительно текущего экземпляра, направления перемещения и родительского экземп-ляра. Выражение записывается на языке программирования M [10, 11].
Текущий экземпляр определяется переменными qqo (код текущего объекта) и qqc (код текуще-го экземпляра), переменная qorder определяет текущее направление перемещения (-1 – к пре-дыдущему экземпляру, 1 – к следующему экземпляру, 0 – остаться на данном экземпляре).
Рассмотрим реализацию операции произведения объектов A и B с помощью ссылочных объек-тов (рис. 3).


Рис. 3 Произведение с помощью ссылочных объектов

Для этого создаётся отображение, в котором объект А объявляется хранимым, объект B поме-щается под объект А и объявляется ссылочным, задаётся выражение для получения следующе-го кода экземпляра относительно текущего экземпляра, имеющее следующий вид:
$Select(qorder=0:qqc, 1:$$Ord(qorder, qqo, qqc, «»))
Данное выражение и использует реализованную в модели функцию навигации по дереву экзем-пляров объектов $$Ord для определения кода экземпляра и подразумевает обход всех экземпля-ров объекта B.
Для описания отображения используется формальный синтаксис Relax NG, изменённый с учё-том структурных компонентов разработанной модели. Отображение объявляется элементов view. Объекты, из которых состоит дерево, объявляются элементом оbj. Вложенность элемен-тов obj соответствует расположению объектов в иерархии дерева. Понятия объявляются эле-ментом woc. Понятия объявляются в пределах объявления объекта, которому они принадлежат. Для рассмотренного примера объявление отображения будет выглядеть следующим образом:
$Select(qorder=0:qqc, 1:$$Ord(qorder, qqo, qqc, «»)) Здесь указано, что объект B в отображении имеет тип ref (ссылочный), кроме того, в элементе ref/expr объекта задано выражение для получения следующего кода экземпляра.
В примере для каждого экземпляра объекта А в дерево экземпляров отображения будут выво-диться все экземпляры объекта B, то есть будет реализована операция произведения.
Операцию произведения с использованием ссылочных объектов можно описать следующим выражением XQuery:
let $base := doc(«base.xml»)
for $a in $base//a
return

{
for $b in $base//b
return
}
Дополнительно, для упрощения записи для ссылочных объектов вместо выражения для получе-ния следующего кода экземпляра в предлагаемой модели вводится список переходов. Выраже-ние для получения следующего кода экземпляра будет построено автоматически на основании списка переходов. Подробно списки переходов будут рассмотрены при обсуждении операции соединения, здесь же следует отметить, что в качестве списка переходов может быть указан код самого ссылочного объекта, в этом случае будут выводиться все экземпляры объекта.
Для данного примера, если в списке переходов указать код объекта B, то для каждого экземпля-ра объекта А будут выводиться все экземпляры объекта B.
Здесь в элементе ref объекта B задан список переходов – код объекта B.
Так как ссылочные объекты ссылаются на хранимые экземпляры, для них допустимы операции коррекции значений, создания и удаления экземпляров.
Виртуальные объекты являются механизмом построения виртуальных деревьев объектов. Вир-туальные объекты используются для представления данных как существующих, так и не суще-ствующих в базе данных. В отличие от ссылочных объектов поведение виртуальных объектов полностью определяется пользователем.
Для виртуального объекта пользователю необходимо определить операцию для получения сле-дующего кода экземпляра относительно текущего экземпляра, направления перемещения и ро-дительского экземпляра. Операция также должна возвращать значения понятий для полученно-го экземпляра. Операция реализуется на языке программирования M [10, 11].
Операция имеет следующий вид:
СodeRes = $$gOrder(Order, Obj, Code, Сode0,.Values)
Параметры операции:
Order – направление перемещения по экземплярам (-1, 1, 0);
Obj – код виртуального объекта;
Code – текущий код экземпляра виртуального объекта;
Code0 – код экземпляра объекта-родителя.
Значение, возвращаемое операцией:
CodeRes – следующий/предыдущий код экземпляра виртуального объекта относительно на-правления перемещения, текущего кода экземпляра и текущего кода экземпляра объекта-родителя. Если операция возвращает «», то происходит переход к следующему коду экземпляра объекта-родителя.
Все значения понятий должны быть записаны в массив следующего вида:
Values(Woc)=Value
Здесь:
Woc – код понятия;
Value – значение понятия.
Код экземпляра виртуального объекта может быть сформирован любым образом, удобным для пользователя.
Рассмотрим реализацию операции произведения для объектов А и В с использованием вирту-ального объекта (рис. 4).


Рис. 4. Произведение с помощью виртуальных объектов

Для этого создаётся объект АВ и отображение, в котором объект АB объявляется виртуальным. Далее для объекта АВ задаётся операция gOrder для получения следующего кода экземпляра и значений понятий экземпляра (рис. 5) и записывается вызов этой операции в свойствах объекта.
$$gOrder(qorder, qqo, qqc, «», .values) Здесь указано, что объект B в отображении имеет тип virt (виртуальный), кроме того, в элемен-те ref/expr объекта задан вызов операции для получения следующего кода экземпляров и значе-ний понятий.
Для данного примера операция gOrder будет иметь следующий вид:
gOrder(order, obj, code, code0, .Values)
{
kill Values(«SName»), Values(«PName»)
new codeA, codeB
set codeA = $extract(code, 1, 2)
set codeB = $extract(code, 3, 4)

if order ‘= 0 {
set codeB = $$Ord(order, «B», codeB, «»)

if codeB = «» {
set codeA = $$Ord(order, «A», codeA, «»)
if codeA’=»" set codeB = $$Ord(order, «B», codeB,»")
}
else if codeA = «» set codeA = $$Ord(order, «A», codeA,»")
}

if codeA ‘= «», codeB ‘= «» {
set Values(«SName») = $$Get(«A», «SName», codeA)
set Values(«PName») = $$Get(«B», «PName», codeB)
}

quit codeA_codeB
}


Рис. 5. Операция получения следующего кода экземпляра и значений понятий

Операция gOrder возвращает коды экземпляров, которые являются сцеплением кодов экземпля-ров объектов А и В, первые два символа кода экземпляра определяются кодом экземпляра объ-екта А, последние два символа – кодом экземпляра объекта В. Значения понятий берутся из со-ответствующих экземпляров объектов-операндов. Таким образом, операция gOrder моделирует операцию произведения.
Операцию произведения с использованием виртуальных объектов можно описать следующим выражением XQuery:
let $base := doc(«base.xml»)
for $a in $base//a
for $b in $base//b
return
{ $a/(*|@*[name() != "code"]) }
{ $b/(*|@*[name() != "code"]) }
Так как экземпляры виртуальных объектов не являются хранимыми, для них запрещены опера-ции создания экземпляров, коррекции значений и удаления экземпляров. Однако эти операции могут быть реализованы пользователем в триггерном действии вместо операции.
Подытожим сказанное о ссылочных и виртуальных объектах. Ссылочные объекты ссылаются на объекты, реально существующие в базе данных, для них операции манипулирования под-держиваются системой. Экземпляры виртуальных объектов не существуют в базе, а создаются пользователем, соответственно, операции манипулирования виртуальным объектом также должны определяться пользователем.
Так как код экземпляра ссылочного объекта есть код экземпляра хранимого объекта, то к тако-му ссылочному объекту можно достраивать потомков этого хранимого объекта. Для того чтобы достроить потомков к виртуальному объекту необходимо использовать ссылочные объекты и задавать для них операцию получения следующего кода экземпляра.
Соединение
В реляционной алгебре операция соединения (?-соединения) возвращает отношение, кортежи которого являются сцеплением кортежей первого и второго отношений и удовлетворяют неко-торому условию.
Эта операция может быть определена на основе операции произведения и выборки следующим образом:
A TIMES B WHERE X ? Y, где
А, В – деревья экземпляров;
X – понятие объекта А;
Y – понятие объекта B;
? – оператор сравнения.
В предлагаемой модели операция произведения может быть реализована с использованием ссылочных или виртуальных объектов. Условие может быть задано для каждого объекта в де-реве объектов либо в выражении для получения следующего кода экземпляра (для ссылочного объекта) или в операции gOrder (для виртуального объекта).
В реляционной алгебре если оператор ? является оператором равенства «=», то такое соедине-ние называется равно-соединением. Результирующее отношение будет включать два атрибута, значения которых в каждом картеже равны. Если исключить один из этих атрибутов, то такое соединение будет называться естественным. Формально эту операцию можно записать сле-дующим образом:
A JOIN B ? A TIMES B WHERE X = Y
В предлагаемой модели перечень понятий каждого объекта задаётся в дерева объектов отобра-жения, кроме того, операция проекции может осуществляться в рамках отображения.
Для упрощения записи операции равно-соединения или естественного соединения с помощью ссылочных объектов в предлагаемой модели вводится список переходов. Список переходов – это список объектов, для которых текущий объект используется как ссылочный. Связь устанав-ливается через равные значения понятий текущего объекта и объектов списка. На основании списка переходов автоматически строится выражение для получения следующего кода экземп-ляра.
С помощью синтаксиса XML список переходов можно определить следующим образом:
Здесь:
Obji – код объекта, для которого текущий объект может быть ссылочным;
Woc0ij – понятие текущего объекта, по значениям которого осуществляется связь;
Wocij – соответствующее понятие объекта Obji, по значениям которого осуществляется связь.
Если код понятия текущего объекта и объекта Obji совпадает, то код понятия объекта Obji мо-жет быть опущен.
Если А – множество экземпляров текущего объекта, то список переходов может быть описан следующим выражением реляционной алгебры:
A REF Obji = (Obji TIMES A WHERE Woc0i1=Woci1 AND … AND Woc0im=Wocim)
Тогда операция соединения определяется на основании списка переходов и операции произве-дения:
Obji JOIN A = Obji TIMES (A REF Obji)
Рассмотрим пример, пусть имеются объекты А и В, в которых пользовательскими потенциаль-ными ключами являются понятия S и P соответственно, и объект АВ, который в реляционном смысле является ассоциацией объектов А и В. Объект АВ содержит пользовательские внешние ключи – S и P, ссылающиеся на соответствующие понятия объектов А и В. То есть, между объ-ектом А и объектом АB, а также между объектом B и объектом АВ реализованы горизонталь-ные связи (рис. 6).


Рис. 6. Соединение с помощью ссылочных объектов

Для реализации операции соединения в отображении объект АВ объявляется хранимым, объек-ты А и B помещаются под объект АВ как дочерние и объявляются ссылочными. Для объекта А задаётся список переходов AB:S, для объекта B – список переходов AB:P, соответственно, реа-лизуются операции соединения AB JOIN A и AB JOIN B.
Здесь указано, что объекты A и B в отображении имеет тип ref (ссылочный), кроме того, с по-мощью элемента ref заданы списки переходов для объектов.
Операцию соединения с использованием ссылочных объектов можно описать следующим вы-ражением XQuery:
let $base := doc(«base.xml»)
for $ab in $base//ab
return

{
for $a in $base//a
where $ab/@s = $a/@s
return $a
}
{
for $b in $base//b
where $ab/@p = $b/@p
return $b
}
Таким образом, с помощью ссылочных объектов горизонтальные связи представляются как ло-гические иерархические связи. Очевидно, такое представление является более наглядным и ин-туитивно понятным для пользователя.
Собственно иерархические связи по кодам экземпляров в предлагаемой модели также пред-ставляют собой реализацию операций соединения между экземплярами родительского объекта (A) и экземплярами дочернего объекта (B) (рис. 7): A JOIN B.


Рис. 7. Реализация иерархических связей
Такие операции выполняются системой автоматически на основании структуры отображения
и могут быть описаны с помощью следующего выражения XQuery:
let $base := doc(«base.xml»)
for $a in $base//a
return

{
for $b in $base//b
where substring($b/@code, 1, $len) = $a/@code
return $b
}
Здесь $len – длина кода экземпляра объекта A, функция substring выделяет из кода экземпляра объекта B значение внешнего ключа, ссылающегося на код экземпляра объекта А.
С помощью ссылочных объектов также предлагается решать задачу инвертирования иерархии по кодам экземпляров. В качестве списка переходов для ссылочных объектов может быть ука-зан код объекта-предка для данного объекта. В этом случае связь осуществляется по кодам эк-земпляров, и в дерево экземпляров попадут те экземпляры объекта, которые являются потомка-ми для экземпляра объекта-предка. Код экземпляра объекта-предка определяется по родитель-скому для ссылочного объекта объекту в отображении. Если в отображении нет родительского объекта для ссылочного или этот родительский объект в отображении не входит в подсхему ба-зы данных, включающую ссылочный объект, то в дерево экземпляров попадут все экземпляры ссылочного объекта. Если в качестве кода объекта-предка указан код самого ссылочного объек-та, то в дерево экземпляров попадёт только один экземпляр для каждого экземпляра объекта-предка.
Дополним предыдущий пример объектом С, дочерним для объекта В, и рассмотрим два вариан-та инвертирования иерархии (рис. 8).

Рис. 8. Инвертирование иерархии
В обоих случаях в отображение помещается объект С как хранимый, под него помещается объ-ект B, который объявляется ссылочным. В списке переходов в первом случае указывается объ-ект А, во втором – объект В.
Для первого случая код экземпляра объекта А (объект-предок) содержится в коде экземпляра объекта С (родительский объект в отображении), в данном случае это код равен А. Соответст-венно, в дерево экземпляров попадут дочерние для А:A экземпляры объекта В – AА и АВ.
Для второго случая код экземпляра объекта В (объект-предок) содержится в коде экземпляра объекта С (родительский объект в отображении), в данном случае это коды АА и АВ. Соответ-ственно, в дерево экземпляров попадут «дочерний» для B:АА экземпляр объекта В, то есть, сам экземпляр AА, а также «дочерний» для B:АB экземпляр объекта В – AB.
Таким образом, в первом случае фактически реализуется операция:
C JOIN A JOIN B ,
а во втором случае операция:
C JOIN B JOIN B ? C JOIN B
С использование XQuery эти операции могут быть описаны следующим образом.
Для первого случая:
let $base := doc(«base.xml»)
for $c in $base//c
return

{
for $a in $base//a
for $b in $base//b
where $a/@code = substring($c/@code, 1, $len_a) and
substring($b/@code, 1, $len_a) = $a/@code
return $b
}

Для второго случая:
let $base := doc(«base.xml»)
for $c in $base//c
return

{
for $b in $base//b
where $b/@code = substring($c/@code, 1, $len_b)
return $b
}

4. Заключение
В разработанной модели данных с помощью предложенных механизмов ссылочных и виртуальных объектов реализуются операции произведения и соединения без создания дополнительных структур хранения, решается задача представления горизонтальных связей как логических иерархических, задача инвертирования иерархии.
Ссылочные объекты ссылаются на экземпляры объектов, реально существующие в базе данных, при этом операции манипулирования экземплярами ссылочных объектов поддерживаются сис-темой. Виртуальные объекты позволяют создавать виртуальные деревья объектов. Операции манипулирования экземплярами должны реализовываться пользователем. Виртуальные объек-ты предоставляют большую свободу и гибкость, однако большинство задач может быть решено с использованием ссылочных объектов.
Предложенная модель данных является основой разработанного инструмента для построения и использования информационных систем qWORD-XML [10]. Благодаря реализованной модели данных, а также унификации хранения, обработки и представления данных, инструмент qWORD-XML представляет собой удобную среду для быстрой и простой разработки, простого сопровождения и использования информационных систем.
С помощью инструмента qWORD-XML были разработаны Автоматизированная информацион-но-аналитическая система по проблемам инвалидности и инвалидов (АИС МСЭ) и Информаци-онно-аналитическая система органов социальной защиты населения субъекта федерации (АИС «Соцзащита»).
Литература:
1 Тимофеев Д.В. Использование платформы XML для описания расширенной реляционной модели данных RM/T
2 Кодд Э.Ф. Расширение реляционной модели для лучшего отражения семантики. http://www.osp.ru/dbms/1996/05/163.htm
3 Extensible Markup Language (XML) 1.0. http://www.w3.org/TR/REC-xml/
4 Relax NG. http://relaxng.org/
5 The Schematron. http://xml.ascc.net/resource/schematron/
6 Document Object Model (DOM). http://www.w3.org/DOM/
7 XML Path Language (XPath) Version 1.0. http://www.w3.org/TR/xpath
8 XML Path Language (XPath) 2.0. http://www.w3.org/TR/xpath20/
9 XQuery 1.0: An XML Query Language. http://www.w3.org/TR/xquery/
10 Гессе С., Кирстен В. Введение в язык программирования М. – СПб: АОЗТ «СП. АРМ», 1996 – 280с.
11 Кирстен В. От ANS MUMPS к ISO M. – СПб: СП.АРМ, 1995 – 277с.
12 Долженков А., Тимофеев Д. Семантический инструмент построения баз данных. «Открытые системы», №01/2006

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

Вторник, Октябрь 21st, 2008
Тимофеев Д.В.
Санкт-Петербургский институт информатики и автоматизации РАН
1. Удержание большего смысла данных
Поставим перед собой задачу создания инструмента для построения баз данных и приложений как задачу представления смысла данных. Как известно, задача представления смысла данных не имеет окончательного решения, это «никогда не завершающаяся задача» [1]. Тем не менее, обсудим некоторые практические шаги в указанном направлении.
На сегодняшний день среди инструментальных средств разработки систем баз данных доминирующее положение занимают системы управления базами данных (СУБД), поддерживающие реляционную модель данных. Для понимания причин повсеместного перехода к реляционным системам нужно знать особенности дореляционных систем (иерархических и сетевых). Рассмотрим присущие им достоинства и недостатки.
Достоинства:
1. Структуры данных, используемые в дореляционных системах, являются наиболее подходящими абстракциями для описания объектов и отношений в реальном мире, то есть наиболее полно отражают семантику предметной области.
2. Развитые средства управления данными во внешней памяти на низком уровне.
3. Возможность построения вручную эффективных прикладных систем.
Недостатки:
1. Доступ к базе данных производится на уровне записей, между которыми поддерживаются явные связи. Следствием этого являются низкоуровневый навигационный стиль программирования и сложность использования таких систем непрограммистами.
2. Отсутствие физической и логической независимости данных. Необходимы знания о физической организации данных. Пользователю самому приходится производить всю оптимизацию доступа к базе данных без какой-либо поддержки системы.
3. Отсутствие теоретической основы. Следует отметить, что понятие модели данных фактически вошло в обиход специалистов в области баз данных только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.
Как известно, целью реляционного подхода было преодоление указанных выше недостатков ранних систем. Реляционные системы в свою очередь характеризуются следующим набором свойств и возможностей:
Достоинства:
1. Наличие простого и в то же время мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных.
2. Обеспечение физической и логической независимости данных. Нет необходимости знать конкретную физическую организацию баз данных во внешней памяти.
3. Единственной конструкцией данных, используемой в реляционной модели, является отношение. Между данными реализуются виртуальные связи (на основании значений данных), а не физические (на основании указателей) как в ранних системах. Следствием являются ненавигационный доступ данных (отношения трактуются как операнды и как результат операции, а не обрабатываются поэлементно). Простота структуры данных и манипулятивных операций в свою очередь облегчает работу пользователей (как программистов, так и непрограммистов).
Недостатки:
1. Примитивность типов данных, используемых в реляционных системах. Вследствие чего присущая реляционным системам ограниченность в так называемых нетрадиционных областях (например, САПР), в которых требуются предельно сложные структуры данных.
2. Слабые возможности по части представления семантики предметной области. Реляционная база данных представляет собой совокупность взаимосвязанных отношений, для которых должны поддерживаться ограничения целостности данных.
Относительно первого недостатка Дейт в [2, 3] отмечает: «Вопрос о том, какие типы поддерживаются, ортогонален вопросу о поддержке реляционной модели». В существующих реляционных системах (SQL-системах) «они являются простейшими, однако ничто в реляционной модели не запрещает им иметь более сложный вид».
Второй недостаток является следствием простоты используемой структуры данных. Реляционная модель достаточна для моделирования предметных областей. Однако проектирование базы в терминах отношений часто представляет очень сложный и неудобный процесс. Потребности проектировщиков баз данных в более удобных и мощных средствах представления предметной области вызвала к жизни направление семантического моделирования.
Расширенные реляционные модели несут большую смысловую нагрузку, чем базовая модель, однако и они не выявляют всю семантику предметной области, термин «семантическая модель» для них не подходит. Основная цель исследований в области семантического моделирования состоит в том, чтобы сделать СУБД более «разумными», в удержании большего смысла данных. Конкретная цель состоит в предоставлении систематического подхода к решению проблемы проектирования базы данных. Общая процедура проектирования базы данных включает следующие два этапа:
1. Использование семантического моделирования для создания концептуальной модели предметной области.
2. Отражение спецификаций модели предметной области в среду конкретной СУБД. Результатом этого этапа является концептуальная схема базы данных в терминах модели данных концептуального уровня выбранной СУБД.
При этом полученная концептуальная схема базы данных может существенно отличаться от первоначальной концептуальной модели предметной области. Для преодоления этого недостатка, а также для решения ряда других задач потребовалось построение специальной системы, названной нами «qWORD-XML». Задачи, которые должна решать эта система будем здесь формулировать в виде требований к проводимой разработке. Сформулируем первое требование.
Требование 1
Система должна основываться на модели данных семантически более полной, чем базовая реляционная модель. При этом модель данных должна быть естественным расширением реляционной модели.
Это позволит в значительной степени упростить отображение концептуальной модели предметной области в концептуальную схему базы данных, а тем самым упростить проектирование и использование баз данных.
Для удовлетворения этого требования в качестве основы qWORD-XML предлагается использовать расширенную реляционную модель RM/T [1]. Рассмотрим важные для нас элементы этой модели.
В RM/T для идентификации сущностей используются суррогаты (определяемые системой идентификаторы). Пользователи базы данных могут заставить систему сгенерировать или удалить некоторый суррогат, но они не имеют контроля над значением суррогата. С введением суррогатов не отменяются ключи, контролируемые пользователями.
Сущности имеют типы. Сущности и их типы классифицируются на три категории:
характеристические сущности – характеристическая сущность выполняют вспомогательную роль в описание некоторой другой сущности;
ассоциативные сущности – ассоциативная сущность выполняет вспомогательную роль в обеспечении взаимосвязи других сущностей;
стрежневые сущности – стержневая сущность не выполняет никакой их указанных выше ролей и обладает независимым существованием.
RM/T поддерживает определённую атомарную и молекулярную семантику. Атомарная семантика представляется n-мерными отношениями (в крайнем случае, бинарными), которые являются наиболее малыми смысловыми единицами, молекулярная семантика представляется смысловыми единицами большими, чем n-мерные отношения. RM/T поддерживает четыре измерения молекулярной семантики – декартову агрегацию, обобщение, агрегацию покрытия и предшествование событий.
Декартова агрегация – это абстракция, в которой связь между объектами рассматривается как объект более высокого уровня.
В RM/T декартова агрегация подразделяется на 3 вида:
1. Агрегация простых свойств, которая образует некоторый тип сущностей (характеристический, стержневой или ассоциативный).
2. Агрегация характеристических сущностей, которая образует некоторый тип сущностей (характеристический, стержневой или ассоциативный).
3. Агрегация любой комбинации стержневых и ассоциативных сущностей, которая образует ассоциативный тип сущностей.
Обобщение – это абстракция, при которой множество схожих объектов рассматривается как родовой объект (подтипы и супертипы сущностей).
Агрегация покрытия – это абстракция, при которой разнородные объекты могут связываться по признаку компонентного вхождения в другие объекты.
Предшествование событий – это абстракция, которая отражает последовательность некоторых типов событий. Сущности типа событий содержат как часть своего описания некоторый момент или интервал времени.
RM/T содержит также расширяемый каталог для предоставления системе сведений о существующих связях между сущностями.
Характеристическая агрегация и обобщение могут быть описаны простой древовидной структурой, а ассоциативная агрегация и агрегация покрытия горизонтальными связями между объектами. Древовидная структура с горизонтальными связями в свою очередь может быть описана компонентами платформы XML (eXtensible Mark-up Language).
В модели данных XML допустимыми структурами являются деревья, узлами которых являются элементы, обладающие атрибутами и содержанием. Для адресации в дереве элементов используется язык XPath, в котором предполагается упорядоченность элементов дерева. Горизонтальные связи между элементами могут быть определены с помощью языков XLink и XPointer.
Для запросов по дереву элементов используется язык XQuery. Для преобразования структуры дерева элементов – язык XSLT. Объектная модель документа DOM описывает функционально полную модель данных XML, так как включает помимо структурных аспектов полный набор возможностей манипулирования данными.
2. Обеспечение динамики существования динамических систем
Сегодняшние подходы к моделированию данных (что реляционный, что объектный) сориентированы в первую очередь на статическое моделирование прикладной области и мало рассчитаны на её динамику. В лучшем случае используется практика «долго и тщательно разрабатывать схему данных, а уж потом фиксировать её и реализовывать в информационной системе», но не эксплуатируется тезис о том, что «введённые данные могут изменяться (а не только пополняться)». Поэтому сформулируем второе требование к разрабатываемой системе.
Требование 2
Система должна учитывать и поддерживать изменчивость и расширяемость схемы базы данных и темпоральную изменчивость данных в период эксплуатации информационной системы. Общая схема базы данных не должна декларироваться явным образом.
Это позволит вести непрерывную разработку приложений в процессе развития и использования информационной системы (обеспечение динамики существования динамических систем).
Для описания древовидной структуры с внешними связями, а также для удовлетворения этого требования в qWORD-XML реализуется модель данных XML, почему разработка и получила такое название.
В такой модели данных для XML-документов могут быть использованы различные языки описания схем, например, XDR, XML Schema, Relax NG, Schematron, которые имеют синтаксис XML. Некоторые языки поддерживают открытую модель информационного наполнения, что означает возможность добавления в XML-документ элементов и атрибутов элементов, которые не были предварительно описаны в продекларированной схеме документа. Следовательно, использование модели данных XML позволяет модифицировать схему данных, не только в процессе создание базы, но и в процессе её эксплуатации.
Темпоральная изменчивость учитывается за счёт поддержки системой темпоральных связей между элементами данных. Такие связи могут быть описаны с помощью языков XLink и XPointer.
Важно отметить такую особенность модели данных XML как отсутствие проблем с null-значениями. Если значение некоторого элемента или атрибута элемента неопределено, то этот элемент или атрибут просто отсутствует в XML-документе. Следовательно, модель данных XML естественным образом подходит для описания разреженных данных.
Фактически, в qWORD-XML иерархическая модель данных в варианте XML накладывается поверх реляционной, что с одной стороны позволяет сохранить строгость реляционной модели, а с другой привнести в неё дополнительную молекулярную семантику [4]. Таким образом, обеспечивается совмещение достоинств реляционной и дореляционных моделей.
Иерархия моделируется как дерево информационных объектов со специфичным для данного объекта набором понятий (реквизитов). Объекты соответствуют элементам XML-документа, а понятия – атрибутам элементов. С другой точки зрения объекты соответствуют реляционным отношениям, а понятия — атрибутам отношений.
Взаимосвязь объектов (дерево объектной структуры) строится за счет специальным образом структурированных суррогатных первичных ключей, то есть между данными реализуются виртуальные связи. Горизонтальные связи объектов могут быть получены за счет использования одинаковых значений понятий в разных объектах. Возможность описывать виртуальные объекты позволяет создавать отображения иерархии, не соответствующей спроектированному дереву.
Понятия объектов могут быть как структурированными (упорядоченное множество слов), так и неструктурированными (текст, рисунок, звук, видео). Слова значений структурированных понятий кодируются суррогатными кодами. Для слов значений создаются домены. Домен представляет собой два словаря: прямой и обратный. Прямой словарь связывает слово значения с суррогатным кодом, обратный словарь – суррогатный код со словом значения. Экземпляр объекта (кортеж отношения) связывает слова значений понятий из различных доменов через их суррогатные коды. Прямой словарь помимо того используется для индексации значений понятий, что позволяет осуществлять быстрый поиск. Кодирование слов значений также решает проблему избыточности данных, свойственную иерархической организации.
Следует также отметить, что в соответствии с [5] qWORD-XML можно классифицировать как естественную (native) модельную XML-СУБД для хранения дата-центричных (data-centric) XML-документов.
3. Оперативная и аналитическая обработка информации
Ещё с давних времён в обработке информации выделялись два уровня: оперативный и аналитический. На практике сегодняшние предприятия используют две отдельные базы данных: базу с оперативными данными, предназначенную для поддержки текущей деятельности организации, и базу с аналитическими данными, предназначенную для поддержки принятия решений.
Системы первого рода называют OLTP-системами (On-Line Transaction Processing – оперативная обработка транзакций), системы второго рода – системами поддержки принятия решения (СППР).
Эти системы в значительной степени отличаются по условиям функционирования и по требованиям к ресурсам. OLTP-системы обычно характеризуются жёсткими требованиями к производительности, предсказуемым уровнем общей нагрузки, небольшими единицами работы и высоким коэффициентом использования. СППР, напротив обычно имеют различные требования к производительности, непредсказуемый уровень нагрузки, большие единицы работы и характеризуются нерегулярным использованием. Теперь можно сформулировать третье требование к разрабатываемой системе.
Требование 3
С помощью qWORD-XML должна быть возможной эффективная реализация как оперативных, так и аналитических информационных систем.
Для обеспечения высокой производительности, очевидно, система не может строиться как надстройка над какой-либо SQL-СУБД или объектной СУБД. Вместе с тем разработка «с нуля» требует гораздо больше времени и усилий, в частности, необходима реализация механизма управления внешней памятью. Поэтому qWORD-XML реализуется как надстройка на M-системой [6, 7].
М – процедурный язык программирования без какой-либо жёсткой парадигмы. M стандартизирован как международными (ISO), так и американскими (ANSI, FIPS) органами стандартизации.
В M отсутствует декларирование переменных, единственный тип данных — это строка символов переменной длины. При вычислении выражений строка может быть проинтерпретирована как число или как логическое значение, поэтому декларации оказываются излишними.
Идея отсутствия деклараций в М естественным образом распространяется и на массивы. Каждая переменная может представлять собой массив с переменным числом измерений, причем память занимают лишь те переменные, которые были определены в программе. В качестве индексов массива разрешены любые строки символов. Переменные могут быть локальными (существующими лишь в оперативные памяти) и глобальными (существующими во внешней памяти). Глобальные переменные в М называются глобалами.
M содержит богатый набор функций для различных манипуляций с текстом. Управление последовательностью операций осуществляется традиционными методами, такими как вызов подпрограммы, ветвление или условное выполнение.
Доступ к локальным и к глобальным переменным обслуживается мощными функциями, обеспечивающими М функциональную полноту системы управления базой данных. Координация доступа к глобальным переменным в многопользовательской среде осуществляется с помощью блокировок, М поддерживает обработку транзакций и сетевое взаимодействие. В M могут быть реализованы все известные модели данных. Вместе с тем следует отметить, что M – это, прежде всего, язык для разработки СУБД, а не собственно СУБД.
Во всех известных М-системах глобалы реализуется через B*-деревья. B*-деревья являются эффективным механизмом управления внешней памятью. Эффективный механизм управления внешней памятью, реализуемой на логическом уровне через глобалы, является главным достоинством М-систем. В этой реализации нет ничего лишнего, благодаря чему решения на M выигрывают по производительности как у SQL-систем, так и у объектных систем.
Практически qWORD-XML реализуется как надстройка над М-системой, в качестве которой могут использоваться системы управления базами данных Cache’ от InterSystems Corporation [8] или GT.M от Sanchez Computer Associates [9]. Эти СУБД обладают всеми характеристиками промышленных систем: высокой производительностью, надёжностью, масштабируемостью, открытостью и переносимостью. Эффективный механизм управления внешней памятью обеспечивает исключительно высокую производительность в системах с большими и сверхбольшими базами данных и большим количеством одновременно работающих пользователей. Ещё один важный фактор – стоимость решения. Решения на базе M-систем выигрывают по стоимости у конкурентов.
Cache’ позиционируется разработчиком как постреляционная СУБД, сочетающая три модели данных и соответственно три доступа к данных: прямой (через глобалы), объектный и SQL-ный. «Постреляционность» реализована с помощью единой архитектуры данных. Она предусматривает единое описание объектов и таблиц, отображаемых непосредственно на многомерные структуры.
Объектное и SQL-ное представление данных находятся на одном логическом уровне. Cache’ может работать на различных платформах: Windows, Linux, основные реализации Unix, Open VMS. Cache’ имеет богатый набор интерфейсов к внешним инструментам проектирования и разработки приложений, работающим по SQL-ной и объектной технологии. Cache’ является коммерческим продуктом и на сегодняшний день наиболее функциональной СУБД на основе М-технологии, к тому же хорошо документированной, в том числе на русском языке.
GT.M может работать на таких платформах как Linux, основные реализации Unix, Open VMS. GT.M имеет открытую архитектуру, программы на M хранятся в виде обычных файлов и компилируются в объектные файлы. Объектные и SQL-ные интерфейсы поставляются на коммерческой основе.
Реализация GT.M на x86 Linux является свободно распространяемой вместе с исходными кодами. По своим встроенным инструментальным возможностям GT.M уступает Cache’, однако благодаря открытости системы имеется возможность реализации собственных интерфейсов.
В качестве платформы для qWORD-XML эти системы нас интересуют в описываемой разработке, прежде всего, благодаря эффективной реализации стандарта M, на котором реализуется процедурная часть qWORD-XML. На M реализуется и набор низкоуровневых операций, соответствующих интерфейсам DOM, для работы с древовидной структурой. Пользовательские хранимые процедуры и триггеры также создаются в виде программ на M, в которых можно использовать эти низкоуровневые операции.
Инструментальные средства Cache’ в значительной степени ускоряют разработку приложений, однако, при эксплуатации информационной системы в качестве сервера можно использовать любую из систем.
4. Универсальная инструментальная среда
Современные промышленные СУБД имеют набор интерфейсов к внешним инструментам проектирования и разработки приложений или снабжаются инструментальными средствами собственного производства. В общем случае мы имеем набор различных инструментов: собственно инструментарий СУБД, среду проектирования базы данных, среду разработки приложений, инструмент для поиска и аналитической обработки данных, генератор отчётов. Соответственно, для построения баз данных и их использования необходимо одинаково хорошо владеть всеми инструментальными средствами, которые могут сильно разниться друг с другом. Поэтому сформулируем четвёртое требование к разрабатываемой системе.
Требование 4
Система должна совмещать инструменты для построения и использования баз данных в рамках единого универсального визуального инструмента.
Это позволит значительно облегчить работу пользователей, ускорить разработку информационных систем и упростить их сопровождение.
Инструментальная среда qWORD-XML может называться универсальным браузером. Универсальный браузер реализуется на Delphi с использованием объекта SftTree фирмы Softel Vdm как клиентское приложение к M-серверу. Delphi – инструмент быстрой разработки приложений на базе объектноориентированного и визуального программирования. В качестве языка программирования используется Object Pascal – объектно-ориентированное расширение Pascal, синтаксис которого более описателен и более удобочитаем, чем, например, синтаксис языка C.
Расширение Object Pascal позволяет использовать всю мощь объектно-ориентированного подхода, который характерен для нового поколения объектно-ориентированных платформ, например, таких как Java. Исполняемые файлы Delphi компилируются чрезвычайно быстро, и скорость работы получившегося приложения сравнима с программами, написанными на C или C++. Таким образом, основными преимуществами Delphi являются простота и удобство разработки, а также высокая скорость работы созданных приложений.
В универсальном браузере взаимодействие с базой данных ведётся через отображения (экранные формы). Отображение описывает либо все дерево объектов, либо его часть в удобном для конкретного рабочего места виде. Отображение состоит в общем случае из дерева объектов, дерева экземпляров объектов и панелей инструментов. База данных проектируется визуально как набор взаимоувязанных объектов.
Экземпляры объектов в отображении показываются в виде дерева-таблицы. Каждый экземпляр объекта может занимать несколько строк и колонок дерева-таблицы для вывода значений своих понятий. Объекты нижнего уровня могут «встраиваться» в произвольные строки объектов верхнего уровня. Понятия одного объекта выводятся в ячейки дерева-таблицы. Помимо значений понятий, в ячейки могут выводиться константы (заголовки) служащие для наглядности представления информации. В описании отображений можно указать множество различных параметров, меняющих внешний вид окна, что позволяет получать традиционные виды экранных форм.
Экранное представление может быть создано с доступом ко всей информации, или за счет параметризации экранных форм, в виде последовательных вызовов экранов, содержащих часть информации в форме бланков или таблиц. Первый вариант удобен для аналитических задач, второй – позволяет построить традиционное оперативное приложение. Отображение также может интерпретироваться как выходная печатная форма. Это позволяет использовать отображения в качестве конструкторов печатных форм. Различных экранных представлений (отображений) базы данных может быть создано сколько угодно.
Универсальный браузер обеспечивает всё работу пользователя с базой данных:
• проектирование структуры базы данных и построение приложений;
• просмотр, ввод и коррекцию информации;
• поиск данных по произвольным запросам;
• аналитическую обработку информации и её графическую интерпретацию;
• формирование выходных печатных форм.
Заключение
Помимо решения перечисленных задач инструмент qWORD-XML имеет ряд важных особенностей и обеспечивает:
• методы идентификации пользователя позволяют создавать различные взгляды на информацию в базе;
• многоуровневую защиту доступа к информации;
• возможность синхронизации информации в территориально-распределенных базах средствами электронной почты;
• различные варианты доступа к базе через Internet;
• возможность интеграции в систему внешних баз данных.
Исходя из сказанного, qWORD-XML представляет собой удобную среду для быстрой разработки баз данных и приложений. Поддерживаемая в qWORD-XML иерархическая модель является для человека более естественным отражением семантики предметной области. Схема базы данных в qWORD-XML не декларируется явным образом и может изменяться в процессе развития и эксплуатации информационной системы. qWORD-XML может использоваться для реализации как оперативных, так и аналитических систем. В рамках универсального браузера совмещаются инструменты для построения и использования баз данных.
Применение разработанного инструмента qWORD-XML оказывается наиболее эффективным для реализации информационных проектов, связанных с использованием значительных по объему массивов данных, например, о населении. Так с помощью qWORD-XML реализуются Автоматизированная информационно-аналитическая система проблемам инвалидности и инвалидов (АИС МСЭ) и Информационно-аналитическая система органов социальной защиты населения субъекта федерации (АИС «Соцзащита»), которые изначально, по объективным причинам, являлись «плохо обусловленными» или «недостаточно регламентированными в своей организации». Таким образом, qWORD-XML открывает технические возможности проектирования систем, ранее практически недоступных для автоматизации.
Также с помощью qWORD-XML реализуются Автоматизированная информационно-справочная и аналитическая система «Реабилитационный восстановительный центр» (РВЦ), Автоматизированная информационная система «Станция переливания крови» (АИС «СПК»), корпоративные автоматизированные системы учёта для служб материально-технического снабжения.
Литература:
1. Кодд Э.Ф. Расширение реляционной модели для лучшего отражения семантики. http://www.osp.ru/dbms/1996/05/163.htm
2. Дейт К. Дж. Введение в системы баз данных, 7-е издание. : Пер. c англ. – М.: Издательский дом “Вильямс”, 2002.– 1072 c.
3. Дейт К. Дж., Дарвен Х. Основы будущих систем баз данных. Третий манифест. Изд. 2-е. : Пер. с англ. – М.: Янус-К, 2004. – 656 с.
4. Веселов В.В., Долженков А.Н. Опыт построения XML-СУБД. – «Открытые Системы», №06/2002.
5. Bourret R. XML and Databases. http://www.rpbourret.com/xml/XMLAndDatabases.htm
6. Гессе С., Кирстен В. Введение в язык программирования М. – СПб.: 1996 – 277 с.
7. Кирстен В. От ANS MUMPS к ISO M. – СПб: 1995 – 277 с.
8. http://www.intersystems.ru/cache/index.html
9. http://www.sanchez-gtm.com/ и http://sourceforge.net/projects/sanchez-gtm