В работе рассматриваются вопросы, связанные с проектированием информационных систем, предназначенных для регистрации данных наблюдений и их анализа, часто называемых системами мониторинга. Данные в таких системах часто слабо или частично структурированы. Их структура может зависеть от конкретного наблюдения и меняться со временем. В общих чертах строится модель данных, ориентированная на задачи мониторинга.
Доминирующей моделью данных в настоящее время является реляционная модель. Тем не менее, было бы рискованным предполагать, что конечный пользователь смотрит на мир с позиций реляционной модели. Для каждого рода деятельности и для сообществ людей, этой деятельностью занимающихся, существует свой взгляд на то, как устроена их предметная область. Цель разработки новых моделей данных состоит в том, чтобы приблизить информационную систему, имеющую дело с некоторой предметной областью к представлениям пользователей об этой предметной области. Более того, если проанализировать современные системы, то окажется, что реляционная модель данных используется в них главным образом для обеспечения хранения данных, а большая часть логики, связанной с предметной областью остается вне компетенции системы управления базами данных (СУБД).
Модель данных, т.е. набор средств описания концептуальной схемы базы данных (БД), используемой СУБД в той или иной степени интегрируется в информационную систему, построенную на ее основе. Действительно, все основные компоненты модели данных - структуры данных, операции и способы описания ограничений целостности должны учитываться при проектировании системы с самого начала, а декомпозиция предметной области на объекты, сущности, отношения, атрибуты, факты и т.д. практически полностью определяется моделью данных, которую привык использовать системный аналитик. Использование понятий и операций, отражающих природу предметной области, значительно снижает затраты на проектирование системы и часто позволяет повысить ее эффективность за счет того, что удается избежать ошибок проектирования, связанных с неадекватным представлением данных. Таким образом, информационная система в целом наследует многие черты модели данных СУБД, главным образом касающиеся подхода к представлению данных.
Построение информационной системы для мониторинга простой предметной области (однородные объекты наблюдения, небольшое фиксированное количество независимых параметров) не составляет особого труда - для этого достаточно использовать какую-либо стандартную СУБД. Дело осложняется, если требуется фиксировать результаты наблюдений над большим количеством объектов разного типа, которые проводятся множеством независимых пользователей, и сохранять данные для последующего анализа.
Данные, регистрируемые разными пользователями для одного и того же объекта, могут противоречить и вообще никак не соотноситься друг с другом. В этом случае использование СУБД, поддерживающих традиционные модели данных, не намного облегчает задачу, поскольку большинство из них ориентированы на фиксацию единой непротиворечивой картины предметной области. (Особенности подходов к моделированию данных и классификация моделей данных представлены в [1].)
Другой особенностью круга задач, рассматриваемого в настоящей работе, является потребность в накоплении сведений о наблюдаемых объектах для их анализа. Современные информационные системы, помимо хранения информации о предметной области, предоставляют пользователям широкий набор средств анализа данных. В последнее десятилетие в теории СУБД появилось целое направление - хранилища данных. Особенностью данной технологии является то, что помимо обычной базы данных, которая рассматривается как моментальный снимок предметной области, существует специальное хранилище, куда время от времени сбрасываются данные. Для того чтобы сделать возможным исторический анализ данных, в соответствии с этой технологией требуется по существу заново спроектировать схему хранилища и постоянно загружать туда информацию из базы данных корпоративной системы. В связи с этим, хотелось бы так организовать информацию, чтобы максимально облегчить ее анализ в режиме реального времени (OLAP) "на месте", на фоне штатного функционирования системы.
В настоящей работе сделана попытка сконструировать в общих чертах модель данных, которая позволяла бы эффективно описывать структуру класса предметных областей, связанных с задачами наблюдения и анализа. Предлагаемая модель данных сочетает в себе два аспекта
Чтобы на конкретных примерах проиллюстрировать, о чем пойдет речь, рассмотрим несколько задач, связанных с наблюдением над объектами реального мира.
1. Медицина и медико-биологические исследования. Врачи осуществляют наблюдения за пациентами. Каждый прием у специалиста сопровождается фиксацией некоторых параметров пациента: фамилия, имя, отчество, страховой полис и/или номер амбулаторной карты больного, рост, вес, пульс, возраст, ЧСС, артериальное давление, жалобы, симптомы и прочее. Кроме того, возможно проведение анализов и инструментальных обследований, при которых фиксируются количественные и качественные параметры. Ряд параметров не изменяется или изменяется крайне редко - это такие параметры как фамилия, пол, адрес пациента, рост для взрослых пациентов. Такие параметры достаточно зафиксировать один раз при первичном приеме Другие параметры (артериальное давление, температура тела) изменяются от одного обследования к другому довольно сильно и требуют постоянного мониторинга. Некоторые параметры могут фиксироваться от случая к случаю, другие фиксируются регулярно. На основании данных обследований могут назначаться те или иные дополнительные обследования. Требуется организовать информацию таким образом, чтобы позволить с минимальными затратами проводить первичные и повторные приемы, т.е. свести к минимуму набор вводимой каждым специалистом информации и исключить повторный ее ввод, обеспечить совместный доступ к информации с ограничением прав доступа для конкретных пользователей, проводить оценку эффективности лечения, обеспечить возможность планирования обследований и лечения, выделение групп риска по различным заболеваниям, а также сделать возможным эффективный статистический анализ - как медицинский, так и финансово-экономический - имеющейся информации. Иногда также требуется проводить экспертизу каких-либо фактов группой специалистов. Описание конкретного примера системы для решения подобных задач можно найти в [2]. В этой работе также подробно обосновывается целесообразность разработки модели данных, ориентированной на задачи мониторинга, и описаны принципы, на которых она должна основываться.
2. Геологический мониторинг. Основным свойством геологической информации является пространственная и временная приуроченность данных. В соответствии с множеством изучаемых процессов проводится комплекс периодических исследований геологических процессов и явлений на постоянных полигонах и в отдельно взятых точках некоторого региона. Разные процессы имеют разную скорость развития, в связи с чем некоторые из них рассматриваются как стационарный фон, а другие нуждаются в исследованиях разной (от столетий до долей суток) периодичности. Результаты исследований накапливаются в единой информационной системе для последующего анализа.
3. Контроль качества. При производстве сложных изделий требуется проводить их испытания разных видов (например, термические, механические и проч.), измеряя ряд параметров и должным образом реагировать на отклонения от заданных значений, в случае необходимости проводя дополнительную диагностику и исследования.
Легко видеть, что во всех описанных случаях имеется некоторое множество объектов реального мира. Имеется также ряд наблюдателей, которые фиксируют некоторый набор параметров этих объектов. Само наблюдение также может выступать в качестве объекта для наблюдения - как в случае с оценкой эффективности терапии или экспертными заключениями. Задачей является наблюдение над объектами, регистрация и контроль их параметров, исследование корреляций или других зависимостей между ними, прогнозирование поведения этих зависимостей, отслеживание критических ситуаций, выработка оценок и решений, оптимальных в текущей ситуации.
1. Проект. Предполагается, что существует какой-то комплекс взаимосвязанных задач или исследований, которые характеризуются достаточно стабильным набором объектов исследования или мониторинга и их свойств, и что с проектом связан достаточно стабильный круг людей (пользователей), которые могут выработать соглашения о предметной области. Проект - это совокупность всех объектов, наблюдений над ними, пользователей и их прав, объявленных типов и т.д. Проект отражает представления группы людей (пользователей) о какой-либо части реального мира (предметной области). Предполагается, что все события в рамках одного проекта происходят по единому времени и для любых двух событий можно определить, какое из них произошло раньше, какое позже.
2. Пользователь. Права доступа к ресурсам системы определяются для каждого пользователя. Для каждого проекта по умолчанию создается один пользователь с ролью "Администратор", который обладает всеми правами и один с ролью "Пользователь", которому запрещено выполнять операции, связанные с администрированием.
3. Сеанс. Сеанс - это последовательность всех действий пользователя, начиная с открытия какого-либо проекта до его закрытия. В рамках одного сеанса пользователь может работать только с одним проектом. В каждый момент времени пользователь может работать только в одном сеансе.
4. Объект. Единственным свойством объектов является их различимость. Для каждого существующего в проекте объекта имеется его уникальная идентификация: каждому объекту всегда поставлено в соответствие некоторое обозначение - идентификатор, который назначается объекту при его создании. Если объект однажды создан в проекте, он не может быть удален.
5. Предопределенные объекты. Будем предполагать, что в любом проекте заранее определено некоторое множество объектов, которые соответствуют числам, строкам и другим распространенным типам данных. В то время как вновь создаваемые объекты обязательно стандартным (независимым от пользователя) образом получают уникальную идентификацию, для предопределенных объектов в качестве их идентификатора используется соответствующая последовательность символов.
6. Параметр (Атрибут). Каждому объекту может быть приписан произвольный набор параметров, описывающий представления пользователей о состоянии и поведении некоторого объекта реального мира. Параметры это то, что можно измерять, наблюдать и изменять в процессе исследований Набор параметров определяется теми задачами, для которых создается проект. Все параметры, использующиеся в проекте, должны быть предварительно объявлены. Каждый объект может иметь, вообще говоря, любой определенный в проекте параметр. В модели предусмотрено некоторое количество предопределенных параметров, которые определены для всех объектов. В качестве примера можно привести параметр "Время Создания", который автоматически фиксируется при проведении любого наблюдения (см. ниже раздел "Операции").
7. Значение. При проведении наблюдения, с рядом параметров объекта, над которым производится наблюдение, связываются значения. Значение является либо идентификатором объекта, либо значением некоторого типа (идентификатором предопределенного объекта). В любой момент времени значением параметра объекта считаются последнее значение либо запрос, присвоенные параметру ранее этого момента. Совокупность значений параметра для данного объекта может представлять собой довольно сложную структуру. Значение параметра может быть неопределенным - все параметры, не определенные для данного объекта имеют зарезервированное значение ^ (или null). Введем еще одно выделенное значение - Т. Если параметр объекта имеет такое значение, то также считается, что значение параметра не определено и, кроме того, значение параметра больше нельзя изменять. Параметр, имеющий значение Т становится "запрещенным" для данного объекта во всех последующих состояниях.
8. Изображения. Каждое значение может быть представлено для пользователя (визуализировано). Это может быть сделано многими способами, - например с помощью форматных преобразований. Рост в метрах может быть записан как 1.5 м, как +1.50 м, как 0.15е+1 м и т.д.
9. Наблюдение (Измерение). В реальном мире мы можем измерять или наблюдать какие-либо характеристики объектов. Для каждого наблюдения определено множество объектов, над которыми оно производится. В качестве значений параметров в контексте какого-либо наблюдения выступают идентификаторы объектов. В этом смысле наблюдение - это просто отношение между объектами, При этом любая связь "Параметр - Объект - Значение" имеет смысл только в контексте какого-либо наблюдения над объектом. Для того чтобы можно было обращаться к результатам наблюдения, это отношение также получает при создании идентификатор, как и любой другой объект. (В некотором смысле понятие объекта - это вырожденное наблюдение, т.е. мы наблюдаем различимость объектов. С другой стороны, наблюдение само может выступать в качестве объекта. Например, мы можем оценивать корректность того или иного наблюдения, делать выводы из значений параметров и т.п., т.е. приписывать наблюдениям какие-либо свойства.) Таким образом, наблюдение позволяет присвоить одному или нескольким параметрам некоторого объекта какие-либо значения (рис.1). Осмысленность параметров и значений для данного объекта остается целиком на совести наблюдателя.
На рисунке наблюдение представлено прямоугольником, объекты - черными кружками, связь между наблюдением и объектом, над которым оно производится - жирной стрелкой, связь между параметрами и их значениями - пунктиром.
Рис. 1.
10. Состояние. Объект в каждый момент времени характеризуется своим состоянием, которое представляет собой совокупность значений всех его параметров, зафиксированных при последних наблюдениях этого объекта, предшествующих данному моменту. Будем называть такое состояние актуальным на этот момент, или просто актуальным, если из контекста ясно о каком моменте времени идет речь. Актуальное состояние в текущий момент времени будем называть текущим состоянием. Будем считать, что пока объект не создан (пока над ним не проведено никаких наблюдений), он находится в неопределенном состоянии ^, в котором все его параметры имеют неопределенные значения ^. Для любых двух состояний объекта можно всегда определить такое, что оно предшествует обоим этим состояниям (или совпадает с одним из них). Еще одно выделенное - терминальное - состояние Т - это состояние, в котором все параметры объекта имеют значение Т. Если все параметры объекта имеют значение Т, то это эквивалентно его уничтожению. Это не означает, что с таким объектом больше ничего нельзя сделать. Объект может быть идентифицирован по какому-либо предшествующему состоянию и параметры объекта могут быть изменены. (См. рис. 2. На рисунке кружки обозначают состояния, стрелка - переход из одного состояния в другое).
Рис.2.
Рассмотрим теперь перечисленные понятия более подробно.
Наблюдение может быть либо новым, первичным, то есть оно производится над новым, вновь созданным объектом, и тогда объект идентифицируется в силу того, что он создан; либо наблюдение может быть повторным, то есть проводится над объектами, над которыми ранее уже проводились какие-то наблюдения, и тогда объект или объекты выбираются на основе ранее зафиксированных параметров, либо через явное обозначение объекта.
При каждом первичном наблюдении возникает, не менее двух объектов: тот, над которым производится наблюдение и само это наблюдение (его представитель), которое можно рассматривать как объект.
Создание нового наблюдения может инициироваться несколькими способами:
Источником информации для наблюдения могут быть вводимые пользователем данные либо данные, автоматически поступающие в вычислительную систему по каким-либо каналам.
При каждом наблюдении состояние соответствующего объекта изменяется. Исходное состояние определяется указанием наблюдения или нескольких наблюдений, которые соответствуют этому состоянию. Если в качестве исходного указывается не последнее наблюдение (т.е. не текущее состояние), то возникает "расщепление" состояний.
Рис. 3
На рис. 3 показано соотношение между наблюдениями и состояниями (si) для одного объекта. Прямоугольники обозначают наблюдения, двойная линия со стрелкой указывает наблюдения, определяющие исходные для наблюдений состояния. Начиная с момента t3 наряду с состоянием s2 возникает s2' и состояние объекта расщепляется.
Чтобы создать новое наблюдение в системе полезно (хотя и не необходимо) заранее описать это наблюдение. Таким образом, возникает понятие типа наблюдения. В типе задаются такие свойства наблюдения, как наиболее характерные параметры объектов, задействованные в наблюдении этого типа, формы представлений для пользователей, формы отчетов и т.п. Некоторые параметры объектов могут не измеряться непосредственно, а выводиться из ранее наблюденных значений. Для таких параметров в типе наблюдения определяются формулы, которые вычисляются при создании нового или повторного наблюдения (после того, как получили значения все параметры, участвующие в формуле).
Тип наблюдения включает в себя задание областей определения параметров, участвующих в нем. Обычно для того, чтобы задавать область определения параметров в моделях данных вводится понятие домена. Например, в модели IDEF1X [3] домен определяется как неизменяемый класс, для которого существует наперед заданное (возможно бесконечное) множество экземпляров. В то же время, на практике понятие домена обычно в чистом виде не реализуется или реализуется только на уровне простых типов данных (домены "целое", "вещественное" и т.п. и их подмножества), т.е. определение домена для какого-либо атрибута эквивалентно определению типа данных для соответствующей переменной включающего языка. Требование неизменности домена возникает из-за того, что если область определения какого-либо атрибута изменяется, то требуется проверить все уже существующие значения этого атрибута на предмет соответствия новой области определения. Более того, если даже это сделано, то непонятно, как быть со значениями, которые больше не принадлежат домену. С другой стороны, возможность ограничения области определения атрибутов изменяющимся во времени множеством сущностей все же поддерживаются через механизмы ограничений целостности, - например, foreign key.
При описании типа наблюдения, для каждого параметра, участвующего в данном наблюдении, может указываться тип значения, которое допустимо для этого параметра. Это означает только то, что, при проведении наблюдения этого типа производится контроль соответствия типа для данного параметра. В других наблюдениях он может принимать значения другого типа. В описании параметра может не определяться его тип - тогда в данном наблюдении он может принимать любые значения, совместимые с глобальным определением типа значения параметра, если таковое имеется.
Для любого наблюдения определены стандартные формы ввода и вывода, которые основываются на стандартных процедурах преобразования значений в изображения для всех параметров. Однако в описании типа наблюдения может присутствовать набор форм ввода (skins) для интерактивной работы и форм вывода (отчетов), определяемый для этого типа наблюдения пользователем. В общем случае могут задаваться процедуры ввода и вывода данных, исполнение которых приводит к присваиванию параметрам значений или их выводу в какой-либо файл.
В типе наблюдения могут описываться ограничения, накладываемые на состояния объекта. Эти ограничения определяют ожидаемое поведение объекта при данном типе наблюдения:
Допустимость состояния определяет соотношение между параметрами объекта, фиксируемыми в данном наблюдении. Например, систолическое артериальное давление никогда не может быть меньше диастолического. Надо отметить, что подобные ограничения являются свойством конкретного типа наблюдения, а не объекта. Так, несмотря на то, что в одном обследовании может присутствовать ограничение на возраст, в другом типе обследования оно может быть снято или изменено.
Для того чтобы описать поведение объекта в динамике, необходимо уметь определять условия перехода из одного состояния в другое. Например, рост здорового взрослого человека не может за короткое время измениться на величину, большую погрешности измерения. Если в анамнезе зафиксирован инфаркт миокарда, то этот факт не может быть изменен. В то же время, эти ограничения в типе наблюдения не означают, что нельзя получить состояние, им противоречащее, при каких-то других наблюдениях.
Одно наблюдение может потребовать проведения предварительно других наблюдений, данные которых должны будут интегрироваться в полученное состояние. В этом случае, в определении типа наблюдения можно указать типы наблюдений, которые обязательно должны быть проведены до данного наблюдения. Для таких наблюдений можно определить, также, что они инициируются перед регистрацией параметров в данном наблюдении.
Помимо наблюдений, которые должны быть проведены предварительно, можно указать совокупность действий, которая должна быть выполнена после окончания данного наблюдения. Эти действия могут, например, быть обусловлены значениями параметров, зарегистрированных при наблюдении.
Итак, при описании типа наблюдения можно указывать такие его характеристики, как
Все параметры должны быть предварительно описаны. Если параметр описан в проекте, то он считается определенным глобально и его можно использовать в любом наблюдении. Параметр может также быть описан только в типе наблюдения. В этом случае он локализован в наблюдениях этого типа и не может использоваться в других.
Хотя значение параметра объекта является в общем случае идентификатором объекта, существует ряд важных частных случаев:
В первом случае существует некоторый эталон, с которым сравнивается характеристика объекта. Таким образом, значения этого типа можно рассматривать как вещественное число вместе с соответствующей размерностью. Иногда подобные параметры (с интервальной или относительной шкалой) характеризуются еще и точностью измерения.
Во втором случае характеристика объекта не может быть точно измерена либо природа этой характеристики не соответствует естественной алгебре вещественных чисел. Такая характеристика принимает значения из специально определенного множества, возможно оснащенного набором каких-либо операций (лингвистическая переменная). Например, для такой характеристики может быть предусмотрено использование булевой алгебры или множеств вида {малый, средний, большой} с соответствующим отношением порядка (ординальная переменная) или набор классов - {мужчина, женщина}, {белый, черный, красный, зеленый} (категориальная переменная).
В третьем случае характеристика объекта может представлять собой сложный объект, который, тем не менее, имеет удобное машинное представление либо представляет собой массив данных, обрабатываемый пользователем. К таким характеристикам можно отнести, например, текстовое описание, видеоизображение, звуковую запись и другие сложные объекты, для обработки которых имеются достаточно удобные и распространенные приложения (стандартные форматы).
Параметры могут задаваться пользователем либо вычисляться автоматически из значений других параметров, если в качестве значения параметра поставляется запрос. Это может быть сделано при проведении наблюдения заранее описанного типа, если в описании параметра ему поставлен в соответствие какой-либо запрос, либо непосредственно в момент проведения наблюдения.
Запрос представляет собой процедуру, которая осуществляет доступ к данным и может поставлять одно значение или множество значений. В простейшем случае запрос представляет собой арифметическое выражение.
Название "вычисляемый" для параметров, с которыми ассоциирован какой-либо запрос, используется по традиции. Такие параметры следует назвать скорее вычислимыми, поскольку при проведении наблюдения такому параметру может быть присвоено любое значение, и тогда формула для его вычисления использоваться не будет.
Вычисляемый параметр может зависеть или не зависеть от других параметров и времени (возможно, транзитивно). В определении формул для вычисляемых параметров запрещены циклические зависимости. В качестве времени для всех вычисляемых параметров в данном наблюдении фиксируется момент начала наблюдения (см. раздел Операции).
Вычисляемый параметр может исполняться только один раз при проведении наблюдения либо каждый раз при обращении к нему. В связи с этим параметры можно разделить на статические и динамические.
Статические параметры вычисляются при проведении наблюдения один раз с использованием некоторого запроса. В дальнейшем их значение не изменяется. Подобные запросы должны поставлять значение и их исполнение не должно вызывать побочных эффектов. Это означает, что процедура вычисления статического параметра не может инициировать проведения других наблюдений либо требовать активности со стороны пользователя. Статический параметр не может также зависеть от динамических параметров.
Если параметр определен как статический, то в системе сохраняется его значение, а не формула, по которой он вычислялся.
Динамический параметр вычисляется каждый раз при обращении к этому параметру. Значением динамического параметра является запрос. В частности, это может быть просто ссылка на текущее значение некоторого параметра другого объекта.
На практике часто встречаются ситуации, когда совокупность объектов и наблюдений над ними разбиваются на группы - по каким-то условиям или произвольно. Эти группы могут различаться природой объектов, значением параметров, ожидаемым поведением. В любом случае, объекты разбиваются на категории, классы, группы. Обычно эта цель достигается либо типизацией объектов, либо дополнительными средствами, такими, как индексные файлы, размещение объектов в разных файлах, объединение объектов в наборы, множества, коллекции и т.д.
Как правило, по условию членства объектов в них различают ручные и автоматические группы. Это связано с тем, что присутствием объектов в группе можно управлять вручную или автоматически. В первом случае членством объекта в группе управляет пользователь с помощью специальных средств. Во втором случае присутствие объекта в группе определяется автоматически на основе условия, определенного через параметры объекта. По существу, автоматическая группа представляет собой запрос, возвращающий не один, а множество объектов.
Для того чтобы далее оперировать с группой объектов как с единым целым, необходимо ввести соответствующий тип данных.
Над значением типа "группа" можно выполнять ряд специфических операций: индексация и выделение подмножества, теоретико-множественные операции, добавление и удаление объектов, перебор, поиск, статистические процедуры и т.д. К группе могут применяться и скалярные операции - в этом случае они применяются к каждому элементу группы.
Эффективность работы с этим типом данных в значительной степени определяется реализацией. Если, например, для каждого нового наблюдения происходит копирование содержимого группы, то это может привести к появлению и быстрому размножению огромных массивов информации. С другой стороны, можно каждый раз сохранять только изменения - тогда массовые операции над группами будут выполняться медленнее, поскольку каждый раз потребуется восстанавливать актуальное состояние группы.
Заметим, что присутствие группового типа данных не является необходимым в модели, поскольку группы объектов могут быть смоделированы многими способами, например, через организацию списков. Однако работать с ним значительно удобнее, чем явным образом перебирать наблюдения и объекты.
Таким образом, в качестве простых типов данных, определенных для значений параметров удобно рассматривать следующие:
Тип значения параметра должен определять область (множество) допустимых значений параметра. Множество может быть задано интенсионально либо экстенсионально на основе множеств, соответствующих другим типам данных. В соответствии с этим возможны следующие определения типа значения параметра:
Предикат может определять принадлежность значения типу не только на основании самого значения. Допустимость того или иного значения может определяться контекстом данного параметра. Например, для женщин и мужчин отличаются интервалы допустимых значений тонуса сосудов головного мозга, содержания гемоглобина в крови в норме и т.п.
В списке допустимых могут присутствовать значения, диапазоны значений разных типов и предикаты. Например, допустимыми значениями для уровня холестерина в крови могут, наряду с действительными числами, быть перечислимые значения {очень низкий, низкий, средний, высокий, очень высокий}
Как уже говорилось, при описании параметра в типе наблюдения можно указать тип значения. В этом случае при проведении наблюдений будет осуществляться контроль типов.
Тип параметра может быть также задан глобально, при его описании в проекте. Тогда контроль типов также осуществляется и, кроме того, тип параметра в описании типа наблюдения должен соответствовать глобально определенному.
При задании типа параметра кроме типа допустимых значений параметра могут указываться также другие характеристики.
При проведении наблюдения параметр может инициализироваться. Возможны следующие варианты:
В первом варианте может быть задано значение или запрос, поставляющий это значение. Запрос исполняется до того, как параметрам присваиваются значения. При инициализации параметра может происходить обращение к какому-либо источнику данных, если эти данные поставляются в автоматическом режиме от устройств регистрации. Таким образом, с помощью инициализации источник может быть определен в типе параметра.
Для параметра могут быть заданы процедуры, которые исполняются при присвоении параметру какого-либо значения и при запросе значения параметра. Это позволяет вызвать побочный эффект при обращении к параметру, например, при задании даты рождения может автоматически устанавливаться значение параметра "Возраст", а при запросе параметра может быть организован учет обращений к нему. В типичном случае эти процедуры отсутствуют.
Обычно для данных, полученных в каком-либо наблюдении, существует период времени, в течение которого их можно считать верными. По истечении этого периода достоверность данных снижается. Например, дата рождения пациента действительна всегда, номер документа, удостоверяющего личность можно считать действительным на протяжении десятков лет, адрес и телефон - на протяжении лет, вес с большой вероятностью не изменяется в течение одного - двух месяцев. Артериальное давление может изменяться каждый день. Поэтому при описании параметра можно задавать его "срок хранения", т.е. время, после истечения которого требуется повторное наблюдение данного параметра. До этого момента параметр в текущем состоянии определяется данными, полученными в последнем наблюдении. После него значение параметра в текущем состоянии становится неопределенным. Таким образом, истечение указанного в определении параметра периода эквивалентно проведению нового наблюдения, в котором этому параметру (и всем, вычисленным с его использованием) приписывается значение ^.
Параметр может быть объявлен как обязательный или необязательный в каком-либо типе наблюдения. Обязательным параметрам в наблюдении этого типа должно быть присвоено значение, отличное от ^. Если параметр объявлен как обязательный и вычисляется на основании других параметров, то все параметры, от которых он зависит, становятся обязательными. Если вычисляемый параметр объявлен как необязательный, то он вычисляется только в том случае, если определены параметры, от которых он зависит.
Таким образом, при описании параметра определяются следующие его свойства:
Как обычно принято в теории СУБД, удобно ввести понятие схемы проекта. Схема содержит совокупность описаний параметров, классы объектов, типы наблюдений, триггеры, процедуры, пользователей, зарегистрированных в проекте и т. д. Рассмотрим вкратце некоторые аспекты организации схемы.
Хотя над любым объектом можно провести любое наблюдение, часто для определенного множества объектов полезно заранее определить типы наблюдения, которые можно проводить над ними. Класс объекта определяется совокупностью типов наблюдения, которые обычно над ним проводятся и допустимыми состояниями для объектов этого класса. Один и тот же объект может участвовать в наблюдениях, которые определены в нескольких классах (т.е. принадлежать нескольким классам).
Помимо ограничений, заданных в типе наблюдения может потребоваться определить дополнительные ограничения для объектов, относящихся к некоторому классу.
Для наблюдений в описании класса объекта может быть задано расписание, на основании которого они могут автоматически проводиться в нужные моменты времени. В расписании может задаваться периодичность наблюдений, конкретное время их проведения, проведение при наступлении какого либо события и другие условия. С помощью расписаний можно описать временную схему событий, которые обычно происходят в проекте.
Может быть определен ряд параметров, характеризующих внешнюю обстановку в целом. Для систем, связанных с управлением финансами, такими параметрами могут быть, например, минимальная месячная оплата труда, курс национальной валюты к остальным валютам и другие, доступные всем и не зависящие от контекста параметры. Кроме того, существует ряд параметров, связанных с жизнью конкретного проекта, такие, как дата его создания, используемые ресурсы и т.д. Поэтому сам проект целесообразно рассматривать в качестве объекта - в этом случае его параметры можно задавать с помощью обычных механизмов. Параметры проекта в целом могут использоваться в качестве триггеров, определяющих наступление того или иного события.
Триггер представляет собой глобально определенную процедуру, применяющуюся к вновь проводимому наблюдению сразу после его окончания и устанавливающую значения каких-либо параметров проекта. Механизм триггеров (сторожков - alerters) и хранимых процедур достаточно широко распространен в СУБД, поэтому не стоит подробно останавливаться на этом вопросе. Триггеры, процедуры и функции, специфичные для данного проекта, также являются характеристикой проекта в целом.
Для каждого проекта предопределена таблица размерностей, в которой содержится информация об основных единицах измерений (например, систем СИ, СГС) и преобразованиях между ними. Пользователи проекта могут добавлять свои собственные единицы.
Очевидно, с системой могут работать одновременно много пользователей. В этом случае должно существовать разграничение прав доступа этих пользователей к объектам и результатам проведенных наблюдений. В случае возникновения противоречия в значениях параметров, касающихся одного объекта, эти противоречивые точки зрения на объект должны отражаться в системе. Соответствующие состояния объекта должны быть равноправны.
Предположим, в системе зарегистрированы два пользователя - u' и u'', которые производят повторное наблюдение объекта o, находящегося в состоянии s1 (рис.4). После проведения этих наблюдений для пользователя u' объект виден в состоянии s2', а для пользователя u'' - в состоянии s2''. Если один из пользователей - u'- дает право доступа к своим наблюдениям пользователю u'', то u'' при повторном наблюдении видит два равноправных актуальных состояния объекта. Он может использовать одно из них в качестве исходного для повторного наблюдения - в этом случае он и далее будет видеть два состояния объекта - либо свести два этих состояния в одно, например, усреднив значения различающихся параметров или выбрав подходящие значения параметров из каждого состояния. Если новое наблюдение не затрагивает параметров, различающихся в расщепленном состоянии, то в этом случае такие параметры неразличимы и расщепление состояния сохраняется. На рисунке кружки обозначают состояния, стрелка - переход из одного состояния в другое.
Рис.4.
Как уже говорилось, расщепление состояний может возникать не только при передаче прав доступа, но и более простым способом - при проведении повторных наблюдений над объектом, когда в качестве исходного состояния принимается не текущее состояние, а одно из более ранних. Один из примеров такой ситуации - анализ "что если", когда одному параметру может быть приписано несколько вариантов значений в качестве гипотез и требуется найти оптимальный из этих вариантов.
Естественным представляется желание построить систему управления правами доступа с использованием тех же принципов и механизмов, которые используются для управления остальными данными.
Проблема прав доступа достаточно хорошо разработана в теории СУБД. Сложностью в предлагаемом подходе является то, что доступно не только текущее состояние объектов, но и их история. Таким образом, необходимо управлять правами доступа во времени, а не только в пространстве. В идеале пользователь даже не должен знать, что его права доступа к объекту ограничены или были ограничены.
Регистрация прав может осуществляться с использованием описанных механизмов. При этом имеет смысл предусмотреть для каждого субъекта общий режим, когда права описываются на уровне ролей, параметров и типов наблюдений и специальный режим, когда могут устанавливаться права исполнения любой операции для каждого пользователя и для каждого состояния.
В общем случае права доступа определяются следующими аспектами:
Подробная разработка и описание языков описания и манипулирования данными не входит в число задач настоящей работы. Поэтому ниже приводится только краткий обзор основных операций, требующихся для работы с объектами, наблюдениями и состояниями, которые следует поддерживать в модели.
Будем предполагать, что имеется ряд оперативных объектов, сопоставляемых объектам, наблюдениям и другим понятиям модели, в частности определены указатель объекта и дескриптор состояния. Указатель содержит идентификатор объекта или наблюдения. Он может также описывать группу объектов. Дескриптор состояния содержит указатели на объект и все наблюдения над ним, по которым строится актуальное состояние, а также временную привязку.
Все операции можно разбить на следующие группы:
Рассмотрим более подробно первые три.
Достаточно рассмотреть только операции, связанные с созданием нового наблюдения, поскольку удаление и изменение выражается через создание новых наблюдений.
Наблюдение возникает в силу самого факта измерения или другой оценки характеристик "объектов реального мира" и поэтому операция удаления к наблюдениям и объектам применяться не должна. Если какое-либо наблюдение признано недействительным, то этот факт просто отражается в системе без реального уничтожения этого наблюдения - начиная с некоторого момента времени объект не будет иметь актуального состояния (точнее он будет находиться в специальном состоянии Т). Точно также изменение каких-либо характеристик означает, что было произведено новое наблюдение, и оно становится "текущим". Будучи зафиксированным в проекте, наблюдение не может быть удалено или изменено. В некотором смысле так в модели автоматически реализуется процедура ведения логического протокола событий. Возможность отката состояния системы на какой-либо момент может быть реализована через создание множества новых наблюдений, повторяющих нужное состояние. В тоже время должна существовать возможность "физически" откатить систему на момент начала транзакции, если эта транзакция завершается аварийно.
Регистрация параметров представляет собой протяженный во времени процесс, поэтому требуются операции обозначающие его начало и конец. Начало и конец наблюдения образуют операторные скобки, соответствующие началу и концу транзакции.
В операцию начала наблюдения может подаваться тип наблюдения - тогда будет создано наблюдение этого типа. Если тип наблюдения не используется, то в наблюдении может участвовать любое количество глобально определенных параметров, в частности, ни одного. Если в операцию подается указатель объекта, то новое наблюдение будет относиться к этому объекту. Если объект в операцию не подан, то он будет создан и ему будет назначен идентификатор. В операции начала наблюдения могут также устанавливаться другие свойства наблюдения, такие как права доступа, ограничения и т.д.
Операция начала наблюдения фиксирует момент, определяющий время проведения данного наблюдения, который далее будет использоваться во всех вычислениях параметров, зависящих от времени.
Наблюдение представляет собой аналог транзакции для последовательности действий, связанной с регистрацией параметров. Действительно, наблюдение соответствует основным характеристикам транзакции - либо фиксируются все параметры, описывающие новое состояние, либо ни один из них. Если какая-то совокупность параметров имеет самостоятельное значение, то она может быть выделена в самостоятельное наблюдение. Одно наблюдение может быть разбито на несколько из соображений удобства или в соответствии с природой объектов. Кроме того, одно наблюдение может потребовать проведения ряда других наблюдений, над другими объектами. Такая ситуация соответствует модели вложенных транзакций, зависимых или независимых.
Операция "Конец наблюдения" определяет момент времени, когда зафиксированы все параметры, которые поставляет в наблюдение пользователь, и начинают исполняться процедуры для статических вычисляемых параметров. Затем происходит запуск системных процедур, устанавливающих триггеры, после чего инициируются наблюдения, непосредственно обусловленные данным наблюдением, причем последнее происходит уже вне рамок транзакции.
Проведение наблюдения состоит из нескольких фаз:
Конечно, тот факт, что в системе в явном виде хранится вся история жизни объектов, несколько осложняет жизнь пользователю, если он хочет видеть только "текущее состояние" предметной области, однако это резко повышает аналитические возможности модели. Кроме того, удобство работы определяется правильно выбранными интерфейсными операциями для навигации во множестве наблюдений и можно организовать интерфейс системы таким образом, что обычному пользователю будет доступно только текущее состояние.
В операции поиска требуется указать следующую информацию:
Если интервал времени не указывается, то считается, что рассматривается текущее состояние объекта. Если же интервал задается, то в условии требуется дополнительно уточнить, когда оно выполняется. Возможны следующие варианты:
Таким образом, каждое логическое выражение в условии поиска может быть предварено указанием на количество наблюдений на данном интервале, удовлетворяющих этому условию ("временной квантор").
Возможны более сложные условия поиска. Если A и B - логические выражения, то можно задавать причинно-следственные связи, например, "Если A, то B до или после A"
Помимо этого, возможно указывать временной интервал непосредственно вместе с каждым простым условием: (A в интервале T1) И (B в интервале T2).
В качестве примера рассмотрим, как мог бы выглядеть запрос на гипотетическом языке манипулирования данными для рассматриваемой модели.
select object о using observations of type General_Info, Visit_To_Phisician on time interval [01.01.2000..01.01.2001] where (о.age > 35 (year)) and (о.age<72 (year)) and (о.gender = femal) and never ( о.systolic_blood_pressure > 130 (mm Hg)) // эквивалентно always not (<condition>) and at least once ( о.wheight / (о.height*о.height) > 30 (Kg/m^2))
Приведенная запись соответствует запросу "Найти всех женщин в возрасте на момент обследования от 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.