Проектирование систем регистрации и анализа данных

Проектирование систем регистрации и анализа данных (Часть 3)

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

Хотя над любым объектом можно провести любое наблюдение, часто для определенного множества объектов полезно заранее определить типы наблюдения, которые можно проводить над ними. Класс объекта определяется совокупностью типов наблюдения, которые обычно над ним проводятся и допустимыми состояниями для объектов этого класса. Один и тот же объект может участвовать в наблюдениях, которые определены в нескольких классах (т.е. принадлежать нескольким классам).

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

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

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

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

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

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

Предположим, в системе зарегистрированы два пользователя - u' и u'', которые производят повторное наблюдение объекта o, находящегося в состоянии s1 (рис.4). После проведения этих наблюдений для пользователя u' объект виден в состоянии s2', а для пользователя u'' - в состоянии s2''. Если один из пользователей - u'- дает право доступа к своим наблюдениям пользователю u'', то u'' при повторном наблюдении видит два равноправных актуальных состояния объекта. Он может использовать одно из них в качестве исходного для повторного наблюдения - в этом случае он и далее будет видеть два состояния объекта - либо свести два этих состояния в одно, например, усреднив значения различающихся параметров или выбрав подходящие значения параметров из каждого состояния. Если новое наблюдение не затрагивает параметров, различающихся в расщепленном состоянии, то в этом случае такие параметры неразличимы и расщепление состояния сохраняется. На рисунке кружки обозначают состояния, стрелка - переход из одного состояния в другое.

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

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

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

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

В общем случае права доступа определяются следующими аспектами:

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

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

Все операции можно разбить на следующие группы:

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

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

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

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

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

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

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

Проведение наблюдения состоит из нескольких фаз:

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

В операции поиска требуется указать следующую информацию:

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

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

Возможны более сложные условия поиска. Если A и B - логические выражения, то можно задавать причинно-следственные связи, например, "Если A, то B до или после A"
Помимо этого, возможно указывать временной интервал непосредственно вместе с каждым простым условием: (A в интервале T1) И (B в интервале T2).

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

Приведенная запись соответствует запросу "Найти всех женщин в возрасте на момент обследования от 35 до 72 лет, обследованных за 2000 год, у которых систолическое артериальное давление за этот период никогда не превышало 130 мм рт.ст. и хотя бы один раз зафиксирован избыточный вес (индекс массы тела >30)"

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

Условия поиска с учетом временных связей между событиями заслуживают более пристального внимания. В частности можно рассмотреть возможность использования диалекта SQL/Temporal или построения специфического языка запросов на основе темпоральной логики [4]. Однако детальная разработка языка не входит в число задач данной работы.

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

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

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

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

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

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

Хочется выразить благодарность А.А. Соловьеву за плодотворные дискуссии и идею широкого использования размерностей в языке.

[1] Klein H.K., Hirschheim R.A. A Comparative Framework of Data Modelling Paradigms and Approaches. The Computer Journal, Vol.30,N 1, 1987, pp 8-15.

[2] Марков Б. Л. Организация данных в системах мониторинга. // Высокопроизводительные вычислительные системы и микропроцессоры. Сборник научных трудов ИМВС РАН за 2000г. М., 2000.

[3] IDEF1X. "FIPS Integration Definition for Information Modelling (IDEF1X)," Federal Information Processing Standards Publication 184, Computer Systems Laboratory, National Institute of Standards and Technology. 1993.

[4]. Manna, Z., Pnueli A.: The Temporal Logic of Reactive and Concurrent Systems. Springer-Verlag, 1992.

Дополнительную информацию Вы можете получить в компании Interface Ltd.

Interface Ltd. Тel/Fax: +7(095) 105-0049 (многоканальный) Отправить E-Mail http://www.interface.ru
	Ваши замечания и предложения отправляйте автору По техническим вопросам обращайтесь к вебмастеру Документ опубликован: 02.04.02