Труды Института системного программирования РАН. Том 13. Часть 2. 2007 г

Предисловие В очередном выпуске «Трудов ИСП РАН», состоящем из двух томов, представлены статьи сотрудников Института и аспирантов, посвященные актуальным аспектам направления open source, разным областям применения технологии тестирования программного обеспечения на основе формальных спецификаций, методам композиции и декомпозиции исполняемых UMLмоделей, интеграции методов интеллектуального анализа данных, вывода на основе прецедентов и адаптивного управления, системам классификации, технологиям темпоральных и объектно-реляционных баз данных, технологии оптимистической репликации, опыту разработки операционной системы реального времени для цифрового сигнального процессора. Во втором томе представлены семь статей. В статье Е.Д. Волковой и А.Д. Страбыкина «Методы композиции и декомпозиции исполняемых UML моделей» рассматриваются способы трансформации исполняемых UMLмоделей, которые основаны на композиции или декомпозиции отдельных частей модели и позволяют облегчить понимание модели и упростить работу с ней; предлагаются и обсуждаются новые виды таких трансформаций, иллюстрируется применение преобразований к различным элементам UMLмоделей. В статье Л.Е. Карпов и В.Н. Юдин «Адаптивное управление по прецедентам, основанное на классификации состояний управляемых объектов» предлагается подход к интеграции методов интеллектуального анализа данных, вывода на основе прецедентов и адаптивного управления в единой самообучающейся системе, позволяющей управлять объектами с плохо формализуемым поведением. В статье Г.Т. Маракаевой «Система классификации химических проб» описывается система классификации, разработанная и реализованная для классификации химических проб. Задача системы классификации состоит в определении класса пробы по заданным значениям атрибутов с использованием ранее накопленных экспериментальных знаний и знаний эксперта. Для классификации химических проб использовался алгоритм на основе разделяющих функций. Целью статьи Б.Б. Костенко и С.Д. Кузнецова «История и актуальные проблемы темпоральных баз данных» является обеспечение знакомства с темпоральными базами данных, текущим состоянием разработок, а также актуальными задачами и дальнейшими путями развития данного направления. Кратко представлена история области исследований темпоральных баз данных и перечислены наиболее значимые поворотные моменты. Изложены основные понятия и термины, идеи и подходы, применяемые в рассматриваемой области. Представлены наиболее важные расширения, дополнения и ответвления в области исследований темпоральных баз данных. 5

Проанализированы направления и состояние исследовательских работ в области темпоральных баз данных, выполняемых в настоящее время. В статье С.Д. Кузнецова «Объектно-реляционные базы данных: прошедший этап или недооцененные возможности?» обсуждается общее понятие объектно-реляционных баз данных. Кратко анализируются основные черты и различия первых версий ОРСУБД компаний Informix, Oracle и IBM. Рассматриваются предпосылки появления ОРСУБД. Выделяются и описываются наиболее важные аспекты языка SQL, имеющие отношение к организации объектно-реляционных баз данных и управлению ими. Анализируется, как реально используются ОРСУБД в настоящее время, и что препятствует их более широкому использованию. В статье В.А. Семенова, С.Г. Ерошкина и др. «Семантическая реконсиляция прикладных данных на основе моделей» рассматривается модельноориентированный подход к семантической реконсиляции данных, описываемых на языках объектно-ориентированного моделирования EXPRESS, UML/OCL, ODL/OQL. На основе статического анализа формальных спецификаций прикладной модели выявляются отношения зависимости и отношения порядка между операциями в конкурентных транзакциях и применяется аппарат логического вывода для выработки непротиворечивых (семантически корректных) и полных (обеспечивающих полноту результирующей транзакции) планов реконсиляции. Обсуждаются конкурентные преимущества предложенного модельно-ориентированного подхода, а также особенности его алгоритмической и программной реализации. Завершается второй том статьей В.В. Рубанова и К.А. Власова «Разработка ОС реального времени для цифрового сигнального процессора», в которой описывается конкретная реализация ОСРВ MicroDSP-RTOS, разработанная в ИСП РАН. Рассматриваются архитектура ОС и предоставляемые ей функции. Обсуждаются доработки в инструментарии кросс-разработки MetaDSP для обеспечения эффективной разработки и отладки многозадачных приложений под платформу MicroDSP-RTOS. Член-корреспондент РАН

6

В.П. Иванников

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

1. Введение Известны три интеллектуальные возможности человека, используемые при разработке программных средств: способность к перебору, способность к абстракции и способность к математической индукции. Однако способность человека к перебору, необходимая при создании и модификации сложных систем, в том числе и программных комплексов, весьма ограничена — в среднем человек может уверенно, не сбиваясь, перебирать в пределах 1000 элементов. Средством преодоления этой ограниченности является способность человека к абстракции, благодаря которой человек может объединять разные предметы или экземпляры в одно понятие, заменять множество элементов одним элементом другого рода, упрощая, тем самым, восприятие. Абстракция лежит в основе моделирования, которое в последнее время получило широчайшее распространение и активно используется в процессе создания программных систем. Наиболее популярным языком моделирования в области разработки программного обеспечения на данный момент является графический язык UML (Unified Modeling Languag — унифицированный язык моделировании) — язык, предназначенный для визуализации, специфицирования, конструирования и документирования программных систем. Выразительных средств этого языка в совокупности с мощными механизмами расширения достаточно для того, чтобы описать любую программную систему, со всех точек зрения, актуальных на различных этапах жизненного цикла. Более того, все шире становится область применения концепций модельно-

1

ориентированной разработки (MDD — Model Drive Development), отводящих моделям главную роль в процессе создания и поддержки системы. В рамках таких подходов собственно разработка сводится к последовательному уточнению модели системы, начинающемуся с абстрактной модели и, заканчивающемуся готовой программной системой. Таким образом, при использовании MDD сложность создаваемых моделей будет напрямую отражать сложность системы, а работа с моделью может создавать такие же трудности, как те, которые возникают при чтении и понимании большого количества исходного кода на традиционных языках программирования. Перечисленные выше факторы обуславливают потребность в методах, позволяющих упрощать восприятие сложных моделей и облегчать работу с ними. В то же время применение таких методов не должно затрагивать важных для пользователей и разработчиков модели свойств системы, например поведенческих, которые в UML задаются при помощи диаграмм конечных автоматов (statemachine diagrams), диаграмм последовательностей (sequence diagrams) и диаграмм деятельности (activity diagrams). Данное свойство сближает такие методы трансформации моделей с известными приемами рефакторинга объектно-ориентированного программного обеспечения. Однако графическая природа языка UML накладывает свою отпечаток на возникающие проблемы и методы их решения. Кроме того, язык UML продолжает развиваться, и последняя на сегодняшний день версия стандарта UML 2.0 включает в себя множество новых элементов, многие из которых могут быть использованы для упрощения восприятия моделей.

2. Конечные автоматы UML Конечные автоматы UML могут описывать поведение следующих элементов исполняемых моделей: активный класс (active class), операция (operation), составное состояние (composite state). В [19] было проведено количественное исследование моделей, используемых в реальных коммерческих проектах. Была составлена представительная выборка таких моделей, анализ которой показал, что, несмотря на наличие достаточно легко понимаемой структуры у почти 90% исследованных элементов модели (диаграмм, автоматов), оставшиеся 10% элементов, как правило, весьма сложны и, более того, именно они специфицируют основную логику работы системы. Таким образом, любые попытки понять и проанализировать поведенческие стороны сложной системы будут наталкиваться на необходимость изучения сложных конечных автоматов, описанных посредством громоздких диаграмм состояний. А так как для любой относительно нетривиальной модификации, количество которых за время жизни программной системы может исчисляться сотнями тысяч, требуется понимание логики работы системы, возникает потребность в методах, упрощающих восприятие системы и облегчающих ее понимание.

Работа выполнена при поддержке РФФИ, проект 05-01-00998-а. 7

8

Суть предлагаемого подхода состоит в том, что исходная модель сложной системы посредством описываемых преобразований трансформируется и дополняется элементами, образуя иерархическое представление, удобное как в случаях, когда нужно получить представление об общих принципах работы системы, так и в случаях, когда необходим детальный анализ конкретных аспектов. Такие преобразования могут быть классифицированы как методы композиции и декомпозиции автоматных моделей. Под композицией в данной работе понимается такое преобразование модели, результатом которого является создание единой новой целостной сущности из нескольких имеющихся сущностей. Например, объединение в одной диаграмме элементов всех диаграмм, описывающих конкретный автомат, есть примитивное преобразование-композиция. Следует отметить, что такая трансформация является примером графической композиции, так как затрагивает только элементы, описывающие графические сущности модели. Как правило, применение композиции способствует получению целостного представления о каком-либо элементе системы; при этом должны быть приняты меры, предотвращающие чрезмерное усложнение создаваемого элемента. Под декомпозицией следует понимать преобразование, обратное композиции, то есть такое преобразование, результатом которого является создание нескольких новых сущностей на основе единственной исходной сущности. Для приведенного примера графической композиции обратным будет преобразование, в результате которого элементы одной диаграммы распределяются между несколькими другими диаграммами. Применяя композицию и декомпозицию, можно построить иерархическое описание сложных элементов системы, облегчающее ее восприятие. При этом понимание работы системы будет происходить сверху вниз по иерархии описания. Сначала пользователь знакомится с основными компонентами описываемой части модели и принципами их взаимодействия, и далее по необходимости углубляется, переходя к более детальному описанию интересующего его компонента. На практике даже для достаточно сложных конечных автоматов редко требуется больше 4-5 уровней детализации. Помимо упомянутого объединения и разбиения на диаграммы, другие способы композиции-декомпозиции автоматов могут быть основаны на использовании такого элемента языка UML, как метки. Их использование позволяет графически отделить участки диаграммы состояний, чтобы, например, перенести их на другую диаграмму или расположить отдельно на исходной диаграмме. Кроме того, введение меток способствует повторному использованию фрагментов диаграмм, так как переход на единожды описанную метку может быть выполнен многократно из различных частей автомата. Однако, так же, как и при написании программ на традиционных языках программирования, использование меток при спецификации автоматов заметно усложняет понимание принципов работы автомата. Особенно затруднительным становится анализ отдельного перехода в автомате, 9

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

3. Методы композиции и декомпозиции для конечных автоматов UML В результате проведённого исследования разработано несколько методов композиции (декомпозиции) конечных автоматов UML. Предложенные методы базируются на двух основных идеях: объединение части состояний конечного автомата в структурную единицу конечного автомата — метод, и формирование иерархической единицы конечного автомата — составного состояния.

3.1. Трансформация «Выделение метода» для конечных автоматов UML Идея трансформации «Выделение метода» состоит в создании нового метода и переносе части исходного автомата в добавленный метод. Данная трансформация во многом аналогична известному рефакторингу «Выделение метода» для объектно-ориентированных языков программирования, описанному в каталоге Фаулера [6]. Суть традиционной трансформации состоит в выделении участка кода и перемещении его в другой метод. Это позволяет сделать код исходного метода более понятным и повышает вероятность повторного использования выделенного метода. Для корректного выполнения традиционного рефакторинга «Выделение метода» требуется тщательный анализ потока данных в выделяемом участке кода, так как все используемые переменные должны быть переданы в метод в качестве параметров, а все изменения переменных должны быть тем или иным образом возвращены исходному методу, если измененные переменные используются в нем далее. Для первичного рассмотрения проблемы выделения метода в автомате эту проблему можно обойти следующим образом. Если используемая переменная является атрибутом автомата или сущности, содержащей автомат, то она будет видна и в выделенном методе и, следовательно, ее не нужно передавать в качестве параметра. Если же используемая переменная является локальной для действий, выполняемых в переходе, то при перенесении всех действий перехода в выделяемый метод определение локальной переменной и все ее использования будут также перенесены. Для выделения метода, в который 10

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

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



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

3.2. Выделение автомата

в

метод

возвратной

части

для состояния X существует возвратная часть конечного автомата, состоящая из одного состояния Y.

конечного Рис. 1. Часть автомата, допускающая выделение метода

Назовём возвратной частью конечного автомата для состояния X группу состояний конечного автомата, в которую есть только один вход из некоторого состояния X, и все переходы, выходящие за пределы группы, попадают обратно в X. Между состояниями, входящими в группу, возможны любые переходы, но существует ровно одно состояние, из которого выполняется переход в группу, и куда попадают все переходы, ведущие за пределы выбранной группы состояний. Согласно исследованию, проведённому в [19], многие конечные автоматы, используемые в промышленных системах, содержат в себе несколько возвратных частей для различных состояний. Многие из них состоят из 1–3 состояний, однако в каждом третьем конечном автомате с большим количеством состояний встречаются возвратные части из 4 и более состояний. Большое количество состояний затрудняет восприятие общей схемы работы конечного автомата. Зачастую, такой конечный автомат приходится описывать на нескольких диаграммах, что нарушает целостность картины. Однако все состояния, входящие в возвратную часть конечного автомата, можно перенести в отдельный метод, что сократит общее количество состояний автомата. Назовём такую трансформацию «выделением в метод возвратной части конечного автомата». Рассмотрим определение части модельного конечного автомата, представленное на Рис. 1. Это автомат допускает выделение метода, так как 11

Рис. 2. Часть автомата после проведения преобразования Extract Method

12

В результате применения трансформации «выделение метода», создаётся метод Proc () с реализацией в виде конечного автомата. Все состояния из возвратной части конечного автомата (в данном примере только Y ) переносятся в выделенный метод. Действия, приписанные переходу в Y, становятся действиями, приписанными начальному переходу конечного автомата метода Proc (). Вместо них в исходный конечный автомат вставляется вызов метода Proc () и команда перехода в исходное состояние X (Рис. 2). Все команды перехода в состояние X в созданном конечном автомате заменяются командами возврата из метода (return) (Рис. 3).

приписанных исходному переходу, добавляется вызов метода Proc () и команда завершения работы автомата (stop). В таком случае преобразованный автомат будет выглядеть так, как показано на Рис. 4:

Рис. 4. Результаты применения второго варианта трансформации

3.3. Выделение в метод последовательной части конечного автомата

Рис. 3. Описание выделенного метода Proc () Часть автомата, выделенная в метод, обладает следующей семантикой: получив сигнал sig3 (), автомат выполняет некоторые действия, начиная с состояния Y, по завершении которых возвращается в состояние X. Подобная логика близка по смыслу к вызову метода — выполнение задачи с последующим возвратом в исходное состояние. Именно это и служит основанием для выделения метода. В результате преобразования выделяется структурная единица автомата — метод, а диаграмма, описывающая конечный автомат, уменьшается, что упрощает его понимание. Выделенный метод можно использовать повторно для уменьшения дублирования кода. Существует частный случай трансформации — выделение в метод группы состояний автомата, все переходы из которых завершают работу автомата, то есть ведут в символ stop. В этом случае выделение метода корректно, если все команды завершения работы автомата в выделенном методе (stop) заменяются командами возврата из метода (return), а вместо действий, 13

Во многих конечных автоматах встречаются последовательные части — несколько состояний, вытянутых в цепочку, с одним входом и одним выходом для каждого состояния (Рис. 5). Согласно исследованию, проведённому в [19], 25 % рассмотренных крупных автоматов содержат последовательные цепочки длинной 3 и более состояний.

Рис. 5. Исходный автомат

14

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

Рис. 6. Описание выделенного метода Proc () Все состояния из последовательной цепочки состояний (в данном примере X, Y и Z) переносятся в выделенный метод. Последний переход цепочки состояний, перенесённый в метод, завершается возвратом из метода (return). Действия, приписанные началу цепочки переходов, становятся действиями, приписанными начальному переходу конечного автомата метода Proc (). Вместо них в исходный конечный автомат вставляется вызов метода Proc () и команда перехода в состояние, следующее за цепочкой (Q) (Рис. 7)

Рис. 7. Результат трансформации 15

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

3.4. Необходимые условия для выделения части конечного автомата в метод Автоматизация проведения преобразований для крупных конечных автоматов является исключительно важной задачей, ибо сложность проводимого анализа способствует возникновению ошибок. Одним из этапов процесса автоматизации является возможность автоматического поиска частей конечного автомата, которые можно поместить в отдельный метод согласно описанным выше подходам. После выделения одного метода могут появляться новые группы состояний, удовлетворяющие условиям выделения метода; поэтому необходимо иметь возможность автоматически выполнять итеративный поиск с возвращением для выявления наиболее оптимальной последовательности трансформаций. Всё выше сказанное подтверждает актуальность и востребованность следующей задачи: сформулировать достаточно формальные необходимые условия для выделения части конечного автомата в метод, общие для всех предложенных трансформаций. Ниже приводятся такие условия. Обозначим переход из состояния а в состояние b по событию sig, выполняющий действия act, через t (a−>b; sig; act). Обозначим конечное состояние автомата через stop, ветвление по условию cond через decision (cond), а конечное состояние процедуры (возврат из процедуры) через return. Тогда, например, переход из ветвления по условию cond в конечное состояние автомата будет обозначаться как t ( decision (cond)−>stop; sig; act). На диаграмме конечного автомата, записанной в нотации UML, кроме стрелок, обозначающих переходы, могут присутствовать следующие элементы: состояния автомата, символы ветвления по условию (decision), начальное состояние, конечное состояние (stop) и символы возврата из процедуры (return). Назовём все эти элементы узлами конечного автомата. Рассмотрим множество узлов N конечного автомата. Назовём узел s  N входным для множества узлов N, если существует переход t (a−>s; sig; act) и a  N. Назовём узел b  N выходным для множества узлов N, если существует переход t (s−>b; sig; act) и s  N. 16

Сформулируем необходимые условия для выделения части конечного автомата в метод: Множество узлов N, не содержащее stop, и все переходы между ними можно перенести в отдельный метод, если для множества узлов N существует ровно один входной узел и не более одного выходного узла. Для поиска частей автомата, которые можно перенести в отдельный метод, должно использоваться то же самое условие. Необходимо искать множества узлов с одним входным и одним выходным узлом. На Рис. 8 приведён пример автомата, удовлетворяющего заданному условию. Данное условие не ограничивает количество переходов, по которым можно попасть во входной или выходной узел, и, как видно на рисунке, для входного узла decision (x) и для выходного узла Q существует по два перехода, ведущие в них.

Все узлы из выделенного множества, decision (x), s1, s2, s3 перемещаются в новый метод Proc (). Переходы, ведущие во входное состояние, после трансформации напрямую направляются в выходное состояние Q. К действиям, выполняемым в этих переходах, добавляется вызов метода Proc () (Рис. 9). Переходы, ведущие в выходное состояние, переносятся в метод и направляются в символ возврата из процедуры (Рис. 10).

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

Рис. 8 Общий вид конечного автомата, удовлетворяющего условию выделения метода

Рис. 9. Результат трансформации 17

18

конечного автомата, очевидно, также удовлетворяют необходимому условию для выделения части конечного автомата в метод. Существуют и другие частные случаи приведённого необходимого условия: 

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



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

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

3.5. Трансформация «выделение составного состояния» для конечных автоматов UML Автоматы, содержащие составные состояния, составляют менее 2 % от всех исследованных в [19] автоматов, что позволяет сделать вывод об их достаточно редком использовании, несмотря на их выразительную мощность. Причиной тому может служить тот факт, что составные состояния не являлись частью языка SDL до его версии SDL-2000. Таким образом, можно предположить, что многим разработчикам моделей, работавшим ранее на языке SDL, недостаточно известна эта конструкция. Тем не менее, введение «составных» или «иерархических» состояний является достаточно важным методом композиции, используемым для создания легко воспринимаемого описания автомата. В следующих параграфах описываются способы выделения составных состояний в конечных автоматах UML.

3.6. Выделение составного состояния для скрытия деталей реализации В промышленных моделях для спецификации поведения объектов достаточно часто используются автоматы, имеющие одно состояние. Такая структура характерна для классов, не обладающих сложной внутренней логикой, а реализующих некоторый сервис для других компонентов системы. В единственном имеющемся состоянии, которое очень часто носит имя “Idle” или “Wait”, объект ожидает запрос на выполнение какой-либо операции. Получение запроса инициирует срабатывание перехода, в процессе которого выполняются необходимые действия. По завершении обработки объект вновь возвращается в исходное состояние. Частота использования подобного приема позволила даже выделить на его основе типичный образец проектирования, получивший название «Ромашка», за счет визуальной схожести описания автомата с цветком. Однако даже в тех случаях, когда 19

Рис. 11. Исходный конечный автомат Для выполнения трансформации выбирается состояние, имеющее возвратные переходы, например Z. Далее это состояние заменяется составным состоянием Z, содержащим одно состояние Z_internals. Для спецификации внутренностей составного состояния Z создается новая диаграмма, на которой определяется начальный переход, ведущий в Z_internals. Все возвратные переходы состояния Z переносятся внутрь этого составного состояния и приписываются состоянию Z_internals. Результаты применения трансформации представлены на Рис. 12 и Рис. 13. В результате применения данного преобразования описание автомата становится более иерархичным и поэтому более удобным для восприятия; структурируются и упрощаются диаграммы, специфицирующие автомат. Выполнение трансформации оправдывается в том случае, когда имеется состояние с большим количеством переходов в само себя. Как правило, наличие многих переходов из некоторого состояния в него же говорит о наличии особой семантической роли у функциональности, реализуемой 20

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

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

3.7. Метод текстового сравнения переходов Как и при написании программ на традиционных языках программирования, при создании UML-моделей крайне желательно избегать дублирования элементов модели, повторно используя вместо этого существующие элементы, так как наличие нескольких копий каких-либо элементов модели может осложнять понимание и модификацию. В контексте исполняемых моделей, специфицированных посредством конечных автоматов, на практике наиболее часто встречаются дублирование общей архитектуры автомата и дублирование переходов. В первом случае в модели будет встречаться несколько похожих на вид, но необязательно эквивалентных автоматов. Избежать дублирования в данной ситуации весьма затруднительно, можно лишь описать повторяющуюся часть автомата как типичный прием проектирования автоматов (pattern), сохранив информацию об использовании этого образца в комментарии к автомату. В случае наличия в автомате эквивалентных переходов дублирование можно устранить за счет применения трансформаций, описанных в следующих параграфах. Однако задача автоматического обнаружения эквивалентных переходов оказывается достаточно сложной и весьма актуальной для больших автоматных моделей. Эквивалентность переходов в автомате означает совпадение списка стимулов, инициирующих эти переходы, а также эквивалентность действий, выполняемых при срабатывании заданного перехода. Если автоматическая проверка эквивалентности списков сигналов, инициирующих сравниваемые переходы, не представляет никакой трудности, то проблема определения эквивалентности двух программ, к которой сводится проверка эквивалентности последовательности действий, выполняемых в переходах, алгоритмически неразрешима. Кроме того, сложно определить критерии эквивалентности двух автоматов.

Рис. 12. Результат трансформации

Рис. 13. Результат трансформации 21

22

Несмотря на это, для конечных автоматов весьма хорошо зарекомендовал себя следующий простой подход, суть которого состоит в сравнении текстовых строк, описывающих переход. При очевидной простоте реализации этот способ позволяет достаточно эффективно находить в автомате эквивалентные переходы. Эквивалентность текстуально совпадающих действий, приписанных переходам, практически очевидна. Достаточно учесть, что оба перехода описаны в контексте одного конечного автомата, и поэтому все использованные при их описании идентификаторы, например, имена функций и переменных, означают в обоих переходах одни и те же объекты. Действительно, каждое имя в переходе либо относится к объекту, объявленному локально, и тогда его определения текстуально совпадают в обоих переходах, и для них можно повторить это рассуждение; либо относится к объекту, определенному в контексте автомата и выше, но в этом случае правила, по которым идентификатору сопоставляется элемент модели, дадут одинаковый результат для обоих переходов, так как их применение в обоих случаях можно начинать с автомата, содержащего оба рассматриваемых перехода, поскольку сами переходы не содержат подходящего объекта. Отсюда следует, что текстуальное совпадение переходов гарантирует их эквивалентность. Тем не менее, отсутствие текстуального совпадения отнюдь не обязательно означает отсутствие эквивалентности: к примеру, если в одном из переходов выполняются действия {a++; b++}, а в другом {b++; a++}, где и a и b являются атрибутами класса, содержащего автомат, то эти переходы можно считать эквивалентными, хотя текстуально они различны. Однако текстуальное сравнение может быть использовано и позволяет получать приемлемые результаты. Метод текстуального сравнения может быть усовершенствован следующим образом: перед сравнением из строк, описывающих переходы, удаляются фрагменты, не имеющие отношения к выполняемым действиям, например, комментарии. Кроме того, все локальные идентификаторы (в случае, если их количество в обоих переходах одинаково) следует переименовать так, чтобы они имели одни и те же имена в порядке их объявления. Автоматизация поиска эквивалентных переходов позволяет упростить процесс применения трансформаций, устраняющих дублирование переходов.

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

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

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

24

Применение данной трансформации к автомату, изображенному на рис. 14, позволяет выделить составное состояние On, содержащее состояния X, Y, Q, Z, если в качестве выделенного перехода использовать переход по сигналу TurnOff (). Для спецификации внутренностей составного состояния создается диаграмма, приведенная на рис. 15, а модифицированный исходный автомат показан на рис. 16. Введение иерархического состояния позволило упростить исходную диаграмму за счет удаления дублировавшихся переходов и сделать ее более наглядной и понятной. Кроме того, замена множества одинаковых переходов одним помогает избежать ошибок при изменении спецификации действий, выполняемых при срабатывании перехода.

либо переход эквивалентный T, либо переход срабатывающий при тех же условиях, что и T.

Рис. 16. Результат трансформации: модифицированный исходный автомат

3.9. Выделение составного возвратному переходу

состояния

по

общему

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

Рис. 15. Результат трансформации: спецификация составного состояния On Создание в автомате S нового составного состояния B, явно содержащего состояния A1…An, корректно в том и только том случае, когда это добавление не нарушает строгую иерархию состояний по включению. Иными словами, новое состояние, будучи изображенным на любой диаграмме состояний, описывающей автомат не должно пересекать границы уже существующих состояний. Перенос перехода T из состояний D1…Dn в состояние E, корректен только в том случае, если E является составным состоянием и не содержит явно никаких состояний кроме D1…Dn, а в каждом из состояний D1…Dn есть 25

Рис. 17. Исходный конечный автомат 26

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

переместить состояния A1…An с исходной диаграммы на диаграмму D (Рис. 19), добавив вместо них состояние В и переход Т к исходной диаграмме (Рис. 18).

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

Рис. 18. Результат трансформации Предлагаемая трансформация выполняется во многом аналогично предыдущей. На первом шаге выделяется множество состояний A1…An автомата S, для каждого из которых существует переход Ti, обладающий следующими свойствами: он срабатывает при условии t, в нем выполняются действия act, и после его завершения автомат возвращается в исходное состояние Ai. К автомату S добавляется новое составное состояние B, содержащее состояния A1…An, а для спецификации состояния В создается отдельная диаграмма D. К автомату S добавляется переход T из состояния B по стимулу t, выполняющий действия act и завершающийся оператором перехода в состояние истории (deep history state). Если у множества состояний A1…An имеется только одна входная точка A1, то возможно дальнейшее преобразование автомата. Все операторы перехода в состояние A1 заменяются операторами перехода в состояние В, а к состоянию В добавляется стартовый переход, ведущий в состояние A1. После этого становится возможным 27

3.10. Выделение составного импортированных из SDL

состояния

для

моделей,

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

В SDL в символе состояния можно перечислить несколько имен состояний, и тогда все переходы, изображенные выходящими из этого символа, будут относиться ко всем перечисленным состояниям. Кроме того, если в качестве имени состояния указать символ «*», то переходы, выходящие из этого символа, будут относиться ко всем состояниям автомата. Также имеется возможность исключить определенные состояния из множества состояний, описываемого символом «*». Умелое использование этих возможностей позволяет значительно упростить описание переходов, применимых более чем к одному состоянию. Результаты статистического исследования показывают, что символ «*» присутствует в 12 % символов состояния, что свидетельствует о достаточно активном использовании этой подстановки и необходимости ее более детального изучения [19]. Отсутствие методов трансформации таких конструкций заставило разработчиков инструментальных средств моделирования пойти по пути внедрения в свои продукты для работы с UML недостающих элементов языка SDL. Так, например, в среде моделирования Telelogic Tau 3.0 поддерживаются «мультисостояния», в том числе, и «*-состояния». Однако для создания моделей, соответствующих стандартному языку UML, необходимо преобразовать подобные состояния в другие элементы, сохранив при этом функциональность автомата. Предлагаемая трансформация упрощает мультисостояния следующим образом. Для каждого символа мультисостояния к исходному автомату добавляется новое составное состояние B, которое содержит в точности все состояния A1…An, перечисленные в символе мультисостояния. Все переходы, приписанные мультисостоянию, переносятся в созданное составное состояние. После этого мультисостояние может быть безболезненно удалено из автомата. Кроме того, если у множества состояний A1…An имеется всего одна входная точка A1, то можно определить отдельную диаграмму для спецификации внутренностей созданного составного состояния B, переместив на нее все описания, касающиеся множества состояний A1…An, заменив при этом в исходной диаграмме все операторы перехода в A1 операторами перехода в состояния В. Пример исходной диаграммы приведен на Рис. 20, а результат преобразования – на Рис. 21. Выделение иерархического состояния также возможно, когда в качестве символа мультисостояния указан «*», то есть определяется переход для всех состояний автомата.

29

Рис. 20. Исходный конечный автомат

Рис. 21. Результат трансформации

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

30

Такое представление, в котором используется нотация SDL для описания переходов, не позволяет понять цельную структуру конечного автомата. Для упрощения понимания была сгенерирована дополнительная OVERVIEWдиаграмма, описывающая весь конечный автомат в нотации UML (Рис. 23). Приведённый алгоритм позволяет найти и выделить из данного конечного автомата три метода. На первом шаге в метод Initialize () выделяются четыре последовательных состояния. На втором шаге выделяется метод Talking (), после чего становится возможным выделить ещё один метод, который назовём Working (). Обратим внимание на то, что выделение метода Working () возможно только после выделения метода Talking (). Процесс применения трансформации итеративный. Поиск частей конечного автомата, которые можно вынести в отдельный метод, можно автоматизировать. В результате применения трансформаций исходный конечный автомат сильно упростился и свободно помещается на одной диаграмме (Рис. 24). Теперь он содержит только одно состояние (вместо четырнадцати состояний в исходном автомате) и вызов двух методов.

Рис. 22. Исходный вид конечного автомата

Рис. 24. Результат трансформации Выделены три метода Initialize (), Talking () (Рис. 25) и Working () (Рис. 28), содержащие 4, 5 и 4 состояния соответственно.

Рис. 23. Краткое описание всего конечного автомата 31

32

Рис. 25. Метод Talking ()

Рис. 27. Составное состояние Talking

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

Рис. 28. Метод Working () Рис. 26. Результат трансформации метода Talking () После данной трансформации, конечный автомат, описывающий поведение метода Talking (), будет перенесён в составное состояние Talking, и из него будут удалены три пары возвратных переходов, что повысит наглядность (Рис. 27). 33

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

34

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

Рис. 29. Результат трансформации метода Working ()

Рис. 30. Составное состояние listening_internals

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

[1] Меллор С., Кларк Э., Футагами Т. Разработка на базе моделей // Открытые системы. 2003. № 12 [HTML] (http://www.osp.ru/os/2003/12/030.htm). [2] Селич Б. Практические аспекты разработки на базе моделей // Открытые системы. 2003. № 12 [HTML] (http://www.osp.ru/os/2003/12/033.htm). [3] Буч Г., Рамбо Д., Джекобсон А. UML Руководство пользователя. — М.: ДМК Пресс, 2001. 432 с. [4] Schmidt D. Model-Driven Engineering // J. Computer. 2006. N 2. P. 25-31. [5] Рамбо Дж., Якобсон А., Буч Г. UML: специальный справочник. — СПб.: Питер, 2002. 656 с. [6] Фаулер М., Бек К., Брант Д., Робертс Д., Апдайк У. Рефакторинг: улучшение существующего кода. — СПб.: Символ-Плюс, 2002. 432 с. [7] Opdyke W. Refactoring Object-Oriented Frameworks. Illinois: University of Illinois, 1992. 151 p. [8] Object Management Group. UML 2.0 Superstructure Specification [PDF, PS] (http://www.omg.org/cgi-bin/doc?formal/05-07-04). [9] Object Management Group. MOF 2.0/XMI Mapping Specification, v2.1 [PDF] (http://www.omg.org/docs/formal/05-09-01.pdf). [10] Object Management Group. OCL 2.0 Specification [PDF] (http://www.omg.org/docs/ptc/05-06-06.pdf). [11] Kovse J., Harder T. Generic XMI-Based UML Model Transformations [PDF] (http://wwwdvs.informatik.uni-kl.de/pubs/papers/KH02.OOIS.pdf). [12] International Telecommunication Union. Specification and description language (SDL) [PDF] (http://www.itu.int/ITU-T/studygroups/com10/languages/Z.100_1199.pdf). [13] Boger M., Strum T., Fragemann P. Refactoring Browser for UML // Revised Papers. International Conference NetObjectDays on Objects, Components, Architectures, Services, and Applications for a Networked World. London, UK: Spinger-Verlag, 2002. P. 366-377. [14] Sunye G., Pollet D., Traon D., Jezequel J.-M. Refactoring UML models // Proceedings. UML'01—Modeling Languages, Concepts, and Tools Fourth International Conference. Toronto, Canada: LNCS, 2001. P. 134-148. [15] Samek M. Practical Statecharts in C/C++. San Francisco: CMP Books, 2002. 387 p. [16] Van Gorp P.; Stenten H.; Mens T., Demeyer S. Towards Automating Source Consistent UML Refactorings [PDF] (http://www.lore.ua.ac.be/refactoringProject/publications/ Towards_automating_source-consistent_UML_Refactorings.pdf). [17] Astels. D. Refactoring with UML // 3rd International Conference on eXtreme Programming and Flexible Proceses in Software Engineering. Marchesi, Italy: M and Succi, 2002. P. 67-70. [18] Mens T., Van Eetvelde N., Janssens D., Demeyer S. Formalising refactorings with graph transformations // J. of Software Maintanence and Evolution. 2004. N 3. P. 10011025. [19] Волкова Е. Д., Страбыкин А. Д. Анализ и трансформации исполняемых UML моделей // Труды Института системного программирования. — М.: ИСП РАН, 2006. С. 171-192.

36

Адаптивное управление по прецедентам, основанное на классификации состояний управляемых объектов1 Л. Е. Карпов, В. Н. Юдин

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

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

1

Работа поддержана грантами Российского фонда фундаментальных исследований № 06-07-89098-а и № 06-01-00503-а. 37

38

2. Исходные понятия Основным в работе является понятие объекта управления (ОУ). Объект подвергается как возмущающим (посторонним для системы управления), так и управляющим воздействиям. Будем называть их входными параметрами объекта. Сам объект характеризуется набором признаков – выходных параметров. Изменения входных параметров влекут за собой изменение выходных параметров. Цель управления – достижение оптимального, в некотором смысле, поведения объекта. Цель решения задачи управления – обнаружение способа изменения во времени входных параметров, при котором выходные параметры обеспечивали бы поставленные цели управления. Такой способ называют стратегией управления. Стратегия должна быть допустимой, то есть должна опираться лишь на те данные об ОУ, которые доступны в соответствующий момент времени (эти данные могут изменяться, например, в результате обновления информации в процессе управления), и обеспечивать выполнение некоторых общих условий протекания процесса управления. Часто ОУ отождествляют с передаточной функцией, отображающей заданное множество входных параметров во множество выходных параметров.

Ō = O (Ī), где Ī – вектор входных параметров объекта управления, Ō – вектор выходных параметров объекта управления. Это отображение может иметь сложную функциональную форму, но обязано удовлетворять двум условиям: 1. 2.

При моделировании процессов управления обычно рассматривают три типа управления:   

Первый тип – разомкнутое управление, которым предполагается наличие цели, определяющей управляющие воздействия для достижения этой цели. Структура разомкнутого управления (рис. 1) проста. Отсутствие обратной связи упрощает управление. При отклонении результата от запланированного проводится анализ, который объясняет причины отклонения, но не ставит задачи изменить что-либо в управлении.

Цель

3. Понятие адаптивного управления Для раскрытия содержания термина адаптивность в теории управления необходимо рассмотреть основные типы управляющих систем. 39

Управление

Результат

Объект

Рис. 1. Структура разомкнутого управления. Второй тип – замкнутое управление (управление с обратной связью), при котором (рис. 2) предполагается возможность изменять управление в зависимости от его воздействия на конечный результат. Эта методика управления рассчитана в основном на малые промежутки времени. Если же результат воздействия фактора проявляется через достаточно большое время, часто возникают значительные затруднения.

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

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

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

Анализ

Управление

Объект

Результат

Рис. 2. Структура замкнутого управления. Третий тип – адаптивное управление отличается от замкнутого наличием модели управляемого объекта (рис. 3), в которой анализируются возможные последствия управления (прогноз). Правильная реакция возможна лишь при построении максимально точной модели объекта, адекватно отображающей среду функционирования и сам объект управления. 40

Прогноз

Управление

Вариант

Модель

Объект

Результат

Рис. 3. Структура адаптивного управления. С термином адаптация связаны понятия адаптивного управления, адаптивной системы и адаптивной модели. 

Адаптация – это процесс изменения параметров и структуры системы, а возможно, и управляющих воздействий на основе текущей информации с целью достижения определенного, обычно оптимального, состояния системы при начальной неопределенности в изменяющихся условиях работы [4, 5].  Адаптивной считают систему, которая может приспосабливаться к изменениям внутренних и внешних условий [4,6]. Адаптивная система сохраняет работоспособность при непредвиденных изменениях свойств управляемого объекта, целей управления или окружающей среды путем смены алгоритма своего функционирования, программы поведения или поиска оптимальных состояний.  Понятие управления с адаптацией (адаптивное управление) – это управление в системе с неполной априорной информацией об управляемом процессе, которое изменяется по мере накопления информации и применяется с целью улучшения качества работы системы.  Адаптивной моделью системы управления объектом считают такую модель, в которой в результате изменения характеристики внутренних и внешних свойств объекта происходит соответствующее изменение структуры и параметров регулятора управления с целью обеспечения стабильности функционирования объекта. Невозможность точной математической формализации структуры объекта, погрешность измерений, отсутствие достоверной информации о начальных координатах, наличие непредсказуемых внешних воздействий предопределяет необходимость реагирования управляющих воздействий на изменения параметров объекта и характеристик внешней среды. Такого рода адаптация (приспособление) происходит путем изменения структуры и параметров регулятора. 41

Конкретизация определения адаптации связана с целями исследования и конструирования. Таким образом, основное свойство адаптивных систем – реализация цели управления в условиях недетерминированной внешней среды и изменяющихся параметров объекта.

4. Управление плохо формализуемыми объектами До настоящего времени модель адаптивного управления рассматривалась разработчиками в основном для управления физическими процессами. Этот подход строится на предположении, что можно получить точную форму передаточной функции, отображающей множество входных параметров во множество выходных параметров управляемого объекта. Областью применения таких методов управления являются хорошо формализуемые, то есть сравнительно простые, объекты управления с очевидными свойствами. На практике же типичными являются объекты управления, которые плохо формализуются, свойства которых априори плохо известны или изменяются в процессе функционирования,. Попытки аналитически описать их свойства быстро приводят к катастрофическому усложнению математических моделей. В ситуации, когда известных параметров ОУ и окружающей среды недостаточно для полного и однозначного определения его поведения, нельзя принимать решение об управляющем воздействии на объект, зная только его входные параметры. Мы будем ближе к знанию поведения объекта, когда управление будет осуществляться не по его параметрам, а по его состояниям. Если удается сформировать на основе априорной информации обобщенные, или агрегированные образы – классы состояний ОУ с известной реакцией объекта каждого класса, то управляющее воздействие можно рассматривать как отображение ОУ из класса в класс (в том числе – в исходный класс). Классы состояний объекта

Класс неуправляемых состояний

…

Рис. 4. Упрощенный вид переходов объекта управления.

42

Разобьем состояния ОУ на группы, состояния в каждой из которых эквивалентны друг другу с точки зрения управления, и назовем их классами состояний объекта (рис. 4). Иногда цель управления состоит в том чтобы достичь или удержать объект в определенном состоянии. Но понятие цели не всегда может отождествляться с конкретным состоянием или классом состояний. Целью может быть управляемое поведение, учитывающее переходы объекта из одного класса состояний в другой. Так, при лечении хронических заболеваний, задача восстановления больного органа – невыполнима, потому при заболевании с той или иной скоростью происходит процесс дегенерации рабочей ткани (мы сейчас не рассматриваем вопросы пересадки органов). Целью управления можно считать стремление замедлить процесс уменьшения рабочей ткани (как можно дольше удерживать ОУ в текущем классе). Казалось бы, эту цель можно заменить более простой – естественным желанием удержать больного в определенной стадии заболевания. Однако, зная, что процесс все равно идет, даже в латентном состоянии (латентное – без заметных признаков заболевания), ставить такую цель – значит обманывать себя. В этом случае управление будет считаться заведомо неудачным. Если же процесс был растянут на достаточно большой (для данного заболевания) срок, значит, цель управления достигнута. Другой пример – управление велосипедом-роботом. Здесь цель – не только удержать равновесие, но и покрыть некоторое расстояние из одного пункта в другой. Исходным классом можно считать начальный пункт вместе с параметрами объекта, в которые входят угол наклона велосипеда и скорость, а целевым классом – конечный пункт с таким же набором параметров. Поэтому, говоря о цели, мы имеем в виду не только состояние, но, прежде всего оптимальное, с нашей точки зрения, поведение объекта, включающее в себя и состояния. Таким образом, управляющее воздействие определяется нами как воздействие на объект с целью достижения оптимального или близкого к нему поведения. При таком подходе поведение ОУ, как при наличии управляющего воздействия, так и без него, представляет собой дискретный процесс, каждый шаг которого, в общем случае, – это переход объекта из одного класса состояний в другой. Следует заранее оговориться, что множество классов состояний объекта не обязательно должно быть упорядоченным, поэтому переход из класса в класс не всегда есть приближение на шаг к цели или отдаление от нее. Формализация такого понятия и возможность упорядочения классов состояний, конечно, во многом зависит от конкретного приложения. При отсутствии управления (или в случае управления, не приводящего к цели) объект может попасть в режим, в котором дальнейшее управление становится невозможным, или бессмысленным. Это может быть как одно состояние, так и 43

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

5. Направления в развитии принятия решений

систем

поддержки

Различают два направления в развитии систем поддержки принятия решений:  

вывод, основанный на правилах; вывод, основанный на прецедентах.

Практически все ранние экспертные системы моделировали процесс принятия экспертом решения как чисто дедуктивный процесс с использованием вывода, основанного на правилах. Это означало, что в систему закладывалась совокупность правил вида "если...то...", согласно которым на основании входных данных генерировалось то или иное заключение по интересующей проблеме. Такая модель являлась основой для создания экспертных систем первых поколений, которые были достаточно удобны как для разработчиков, так и для пользователей-экспертов. Однако с течением времени было осознано, что дедуктивная модель моделирует один из наиболее редких подходов, которому следует эксперт при решении проблемы. Идея вывода по правилам является привлекательной, потому что она подразумевает наличие хорошо формализованной задачи, для которой существуют научные методы, доказавшие свою применимость и позволяющие получить решение, не требующее дополнительных доказательств. Но окружающий мир сложен. Существует много слабо формализованных задач, для которых, возможно, будут найдены решения. Кроме того, существует ряд задач, для которых никогда не будет найдено формальное решение (судопроизводство, медицина). Актуальность проблемы обусловлена и многочисленностью таких задач, и практической потребностью найти хотя бы одно сколько-нибудь подходящее решение там, где из-за отсутствия формализованного метода нельзя найти все решения или оптимальное решение. На самом деле, вместо того чтобы решать каждую задачу, исходя из первичных принципов, эксперт часто анализирует ситуацию в целом и вспоминает, какие решения принимались ранее в подобных ситуациях. Затем он либо непосредственно использует эти решения, либо, при необходимости, адаптирует их к обстоятельствам, изменившимся для конкретной проблемы. 44

Моделирование такого подхода к решению проблем, основанного на опыте прошлых ситуаций, привело к появлению технологии вывода, основанного на прецедентах (Case-Based Reasoning, или CBR), и, в дальнейшем – к созданию программных продуктов, реализующих эту технологию.

6. Вывод, основанный на прецедентах Вывод на основе прецедентов – это метод принятия решений, в котором используются знания о предыдущих ситуациях или случаях (прецедентах). При рассмотрении новой проблемы (текущего случая) находится похожий прецедент в качестве аналога. Можно попытаться использовать его решение, возможно, адаптировав к текущему случаю, вместо того, чтобы искать решение каждый раз сначала. После того, как текущий случай будет обработан, он вносится в базу прецедентов вместе со своим решением для его возможного последующего использования. Более формальное определение дано в [7]. Прецедент – это описание проблемы или ситуации в совокупности с подробным указанием действий, предпринимаемых в данной ситуации или для решения данной проблемы. Согласно [8], прецедент включает: 1. 2. 3.

Описание проблемы. Решение этой проблемы. Результат (обоснованность) применения решения.

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

45

Рис. 5. Цикл вывода на основе прецедентов Прецедент может содержать не только положительный исход. Тот факт, что больной не почувствовал улучшения в результате примененного лечения, надо также сохранять в ведущейся базе прецедентов, чтобы избежать подобных исходов в будущем. Объяснение того, какой отказ произошел и почему, может быть использовано при лечении других пациентов. Некоторые системы могут сохранять обоснование решения и даже его альтернативы. Имеются много способов представления прецедента: от записей базы данных, древовидных структур до предикатов и фреймов. Представление должно соответствовать целям системы. Проблема представления прецедента – это прежде всего проблема решения, что сохранить в прецеденте, нахождения соответствующей структуры для описания содержания прецедента и выбора способа организации и индексирования базы знаний прецедентов для эффективного поиска и многократного использования. 46

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

3. 4.

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

Адаптация решения

Управление

Прогноз

Объект

Выбор прецедента

Результат

Текущая ситуация

Сохранение прецедента

Рис. 6. Схема адаптивного управления по прецедентам. Наполнение базы прецедентов может происходить как до момента начала управления на основе априорной информации, с помощью реальных или смоделированных прецедентов, так и в процессе управления, после обработки итога управляющего воздействия. Классификация состояний ОУ может производиться с привлечением экспертного знания или путем предварительной кластеризации. Схема адаптивного управления, приведенная на рис. 3, в этом случае будет выглядеть иначе (рис. 6). 47

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

Формирование обобщенных образов состояний ОУ на основе априорной информации (обучение). Идентификация состояния ОУ по его выходным параметрам (задача распознавания образов). Определение влияния входных параметров на перевод ОУ в различные состояния (обратная задача распознавания). Прогнозирование поведения ОУ в условиях полного отсутствия управляющих воздействий. Прогнозирование поведения ОУ при различных вариантах управляющих воздействий.

8. Выбор прецедента В таких системах одной из самых важных является проблема выбора подходящего прецедента. После того, как прецеденты извлечены, нужно выбрать "наиболее подходящий" из них. Это определяется сравнением признаков ОУ в текущей ситуации и в выбранных прецедентах. Определение метода, на котором будет основываться нахождение меры сходства прецедентов, решается во время создания системы ее разработчиками. Наиболее популярным и часто используемым является метод «ближайшего соседа» [9]. В его основе лежит тот или иной способ измерения степени близости прецедента и текущего случая по каждому признаку (будь это текстовый, числовой или булевский), который пользователь сочтет полезным для достижения цели. Говоря более строгим языком, вводится метрика (расстояние) на пространстве всех признаков, в этом пространстве определяется точка, соответствующая текущему случаю, и в рамках этой метрики находится ближайшая к ней точка из точек, представляющих прецеденты. Описанный здесь алгоритм очень прост. Реально применяются некоторые его модификации. Обычно прогноз делается на основе нескольких ближайших точек, а не одной. Такой метод более устойчив, поскольку позволяет сгладить отдельные выбросы, случайный шум, всегда присутствующий в данных. Каждому признаку назначают вес, учитывающий его относительную ценность. Полностью степень близости прецедента по всем признакам можно вычислить, используя обобщенную формулу типа:

48

 w  sim(x , x j

ij

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

kj)

j

w

j



j

где

wj

– вес j-го признака, sim – функция подобия (метрика),

xij

и

xik

–

значения признака xj для текущего случая и прецедента, соответственно. После вычисления степеней подобия для всех прецедентов получаем их единый ранжированный список. Метод прост, может быть реализован очень эффективно, но требует для работы большой памяти, так как в процессе нахождения значения зависимой переменной для новой записи используется вся существующая база данных. В методе ближайшего соседа, в классическом его представлении, используются только признаки текущего случая и прецедента. Но в управлении важен еще и результат воздействия, то, насколько он приближает к цели. При вводе метрики можно учесть и этот критерий. Считая, что цель должна быть достигнута за конечное число шагов, можно считать более близким прецедент, позволяющий достичь цели за меньшее число шагов. Мы пока не рассматриваем более сложные случаи управления, когда прецеденты выстраиваются в определенный порядок (в общем случае – в некоторые структуры). Так, например, в медицине лечение иногда проводят этапами, выводя больного из комы сначала в некоторое промежуточное состояние, не граничащее с комой, а затем уже стараются приблизить его показатели ближе к норме. В общем случае, можно представить многоуровневую метрику, где прецеденты сравниваются по: 1. 2. 3.

Состоянию до воздействия; Воздействию; Состоянию после воздействия.

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





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

Процесс адаптации может быть весьма сложным; в большой степени он зависит от проблемной области.

10. Понятие метрики

локальной

контекстно-зависимой

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

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

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

11. Описание метрики

локальной

контекстно-зависимой

Существуют разные способы разбиения множества объектов на классы: 1.

2. 3.

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

Локальная метрика, основанная на классах эквивалентности, делит все объекты на две группы: входящие в один класс с текущим и не входящие в этот класс. Она может принимать только два значения. Если исследуемый объект попал в класс, то близкими (равными по метрике) ему могут считаться объекты этого же класса. Остальные – не равны. Такая метрика не полностью учитывает взаимоотношения между текущим объектом и окружающими (контекст), особенно когда объект попадает в область пересечения классов. Формирование классов происходит до рассмотрения исследуемого объекта и естественно, не в его признаковом пространстве. На этапе предварительной обработки, когда объекты собирают в классы, признаковым пространством для класса будет пространство, общее для всех признаков этого класса. Далее, после того, как классы сформированы, естественно рассматривать их в общем для них признаковом пространстве (в транзитивном замыкании пространств всех объектов). 52

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

Расстояние от текущего объекта до другого равно разности количества классов, куда попал текущий объект, и количества классов из этого числа, в котором находится другой.

1.1. A

1.2. B

O

пересечения. Этому можно найти простое объяснение: если считать, что введением классов мы разбили множество объектов на основные понятия, то с тем же набором признаков, что и текущий объект, они подобны ему по принадлежности к понятиям, обозначаемым классами. Сравнив введенное понятие близости с тем, что говорилось ранее, нетрудно заметить, что предложенная метрика является локальной и контекстнозависимой. Локальной, потому что привязана к рассматриваемому объекту, контекстно-зависимой – потому что зависит от его набора признаков. Приведем более строгое определение предлагаемой меры:

X1

Рис. 7. Отнесение недостаточно описанного объекта к двум классам. Два непересекающихся класса A и B описаны в пространстве признаков {X1, X2}. Объект исследования O представлен одним признаком X1, признак X2 у него отсутствует. В этом пространстве признаков {X1} проекции классов пересекаются, и объект попадает в это пересечение. Для более точной оценки нужно было бы добавить к контрольному объекту значение признака X2 (так же поступают и в медицине: если имеющихся показателей не хватает для дифференцирования заболеваний, только дополнительное исследование позволит сделать окончательный вывод), но на практике это не всегда возможно. До сих пор считалось, что попадание объекта в область пересечения классов является препятствием для оценки объекта. Поскольку от этой ситуации избавиться не удается, ее надо постараться использовать. Для этого будем использовать аналоги – объекты соответствующих классов, попадающие в ту же область пересечения. При рассмотрении объекта соответствующая ему точка сравнивается с расположением классов в проекции на пространство его признаков. Другие объекты, входящие в один класс с ним, считаются близкими к нему. Объекты могут также попадать в область пересечения классов. Все объекты можно разделить на группы (рис. 8), основываясь на сложности этого пересечения. Объекты, находящиеся в той же области пересечения, что и исследуемый объект, естественно считать более близкими к нему, чем те, которые находятся вместе с ним в каком-нибудь одном из классов, не входя в область 53

Это значит, в частности, что расстояние между текущим объектом и другим объектом, находящимся в той же области пересечении классов, равно нулю. На рис. 8 цифрами помечены области с соответствующим этим цифрам расстоянием от текущего объекта до объекта из этой области. Предложенная мера не является метрикой в классическом понимании, а только имеет интерпретацию расстояния. Для нее не гарантируется выполнение правила симметричности, потому что она привязана к объекту, и, при переходе к другому объекту, будет рассматриваться уже в его пространстве признаков. По этой же причине не гарантируется выполнение правила треугольника. Однако она позволяет учитывать контекст взаимоотношений объекта с окружающими, особенно в непосредственной близости от него. Текущий объект 2 1 0 1 2

Рис. 8. Степени близости объектов.

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

отнести, в первую очередь, медицинские приложения, затем управление предприятием, игру на валютном рынке, системы защиты информации (обнаружение информационных воздействий) и другие. Адаптивное управление предприятием, или «включенное» оперативное управление чаще подразумевает собой действия, направленные на преодоление кризисной ситуации на предприятии [10]. Модель адаптивного управления должна содержать критерий, относительно которого принимается решение, и характеристики объекта в виде совокупности управляемых переменных. Управление должно происходить в условиях неполного, нечеткого и неточного знания характеристик объекта управления и характеристик окружающей среды, в которой функционирует этот объект. Кроме того, в ходе реализации экономического процесса, происходящего в условиях неопределенности, обычно меняются параметры объектов-участников процесса и характеристик окружающей их среды. В такой ситуации не представляется возможным получить четкую форму модели объекта управления, как параметрическую, так и структурную. Метод управления по прецедентам предлагается в качестве основы реализации таких адаптивных регуляторов экономических процессов. В настоящее время становится очевидным, что качественно новый уровень защищенности сложных и многофункциональных информационных систем может быть достигнут лишь за счет реализации адаптивного управления процессами защиты информации. При этом под "адаптивным управлением" понимается процесс целенаправленного изменения параметров и структуры системы защиты информации с целью поддержания требуемого уровня защищенности систем. Современные сетевые технологии уже трудно представить без механизмов защиты. Однако при их детальном анализе всегда возникают несколько вопросов: насколько эффективно реализованы и настроены имеющиеся механизмы, как противостоит атакам инфраструктура защиты, может ли администратор безопасности своевременно узнать о начале таких атак? Противостояние атакам – важное свойство защиты. Казалось бы, если в сети установлен межсетевой экран (firewall), то безопасность гарантирована, но это распространенное заблуждение может привести к серьезным последствиям. Например, межсетевой экран не способен защитить от пользователей, прошедших аутентификацию. А квалифицированному хакеру не составляет труда добыть идентификатор и пароль авторизованного пользователя. Кроме того, межсетевой экран не только не защищает от проникновения в сеть через модем или иные удаленные точки доступа, но и не может обнаружить такого злоумышленника. Обнаружение атак – это процесс оценки подозрительных действий в корпоративной сети, который реализуется посредством анализа журналов регистрации операционной системы и приложения (log-файлов) либо сетевого 55

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

13. Заключение Интеграция трех самостоятельных направлений, относящихся к методам генерации нового знания и использования этого знания при управлении поведением объектов, позволяет получить новый импульс в развитии интеллектуальных средств управления. В работе показаны возможные выгоды от такой интеграции, наибольший интерес из которых представляет, повидимому, возможность накапливания знаний о возможном поведении в случае возникновения каких-либо ситуаций и постоянно растущая вероятность верного прогноза поведения в ситуациях, ранее не встречавшихся или ранее не явно не распознававшихся. Особенным достоинством метода является возможность накопления знаний о ситуациях (прецедентах) во внешней, по отношению к объектам, базе данных и использования этих знаний другими объектами, подключенными к той же базе. Метод важен и интересен тем, что его можно применять по отношению к реальным биологическим объектам, в том числе – при изучении поведения человека. Адаптация поведения любого живого существа, в том числе, человека, в окружающей среде, с момента рождения происходит на основе прецедентов. В начальной стадии жизнедеятельности один из основных способов накопления знаний (пополнения базы прецедентов) – это игра. Когда собственная база прецедентов мала, собственный опыт проб и ошибок оказывается незаменимым, особенно он важен, если плата за ошибки относительно мала. Одновременно база прецедентов начинает пополняться чужим опытом (например, с помощью наблюдения), иными словами, происходит процесс передачи знаний от одной системы управления в другую. Развиваемый подход не является панацеей и не может быть абсолютизирован. В определенных ситуациях, связанных управлением и обучением объектов с хорошо формализуемым поведением, применение "классических" методов будет, несомненно, более выигрышным. Однако метод интеллектуального адаптивного управления с предварительной и перманентной классификацией новых ситуаций позволяет работать с объектами, поведение которых слабо 56

изучено или (в начальный момент) совсем неизвестно, расширяя сферу применения всех трех методов: адаптивного управления, добычи данных и вывода на основе прецедентов. Литература [1] Я. З. Цыпкин. "Адаптация и обучение в автоматических системах". М.: Наука, 1968. [2] Н. Г. Загоруйко. "Прикладные методы анализа данных и знаний". Новосибирск, ИМ СО РАН, 1999. [3] Л. Е. Карпов, В. Н. Юдин. "Методы добычи данных при построении локальной метрики в системах вывода по прецедентам", М., ИСП РАН, препринт № 18, 2006. [4] В. И. Скурихин, В. А. Забродский, Ю. В. Копейченко. "Проектирование систем адаптивного управления производством". Харьков, “Вища школа”, 1984. [5] А. А. Жданов. "Метод автономного адаптивного управления". Известия Академии наук. Теория и системы управления, 1999, № 5, стр. 127-134. [6] Математика и кибернетика в экономике. – М.: Экономика, 1975. [7] Alan Bundy, editor. "Artificial Intelligence Techniques". Springer Verlag, 1997. [8] Klaus-Dieter Althof, Eric Auriol, Ralph Barlette, and Michel Manago. "A Review of Industrial Case-Based Reasoning Tools", AI Intelligence, 1995. [9] S. S. Anand, J. G. Hughes, D. A. Bell and P. Hamilton. "Utilising Censored Neighbours in Prognostication, Workshop on Prognostic Models in Medicine", Eds. Ameen AbuHanna and Peter Lucas, Aalborg (AIMDM’99), Denmark, pp. 15-20, 1999. [10] В. В. Кузьменко, Д. В. Гришин. "Теоретические аспекты функционирования адаптивной системы управления предприятием". Вестник СевКавГТУ. Серия «Экономика». № 2 (10), 2003. ISBN 5-9296-0140-2. Северо-Кавказский государственный технический университет (www.ncstu.ru).

57

Система классификации химических проб Г.Т. Маракаева

1. Введение В данной статье описывается система классификации КХП (Классификатор химических проб), разработанная и реализованная в Московском университете для классификации химических проб. Задача системы классификации состоит в определении класса пробы по заданным значениям атрибутов с использованием ранее накопленных экспериментальных знаний и знаний эксперта. Для классификации химических проб был выбран алгоритм на основе разделяющих функций [1], подробно описанный в работах [2, 3]. Для ускорения классификации в системе предусмотрена возможность использования дерева классов, соответствующих качественным признакам исследуемых проб, которое задается экспертом во время обучения системы. В случае, когда указанное дерево классов определено, его использование позволяет выделить для исследуемой пробы поддерево (подмножество) потенциальных классов и строить разделяющие функции только для выделенного подмножества классов. Система состоит из набора подсистем, которые программируются на основе набора прикладных интерфейсов (API). Эти интерфейсы используются для реализации новых подсистем системы КХП или для модификации существующих подсистем. Процесс приспособления системы к конкретной задаче классификации называется настройкой системы. Настройка системы позволяет менять свойства системы в достаточно широких пределах. Она осуществляется системным программистом – администратором системы. Помимо настройки в системе предусмотрен процесс обучения системы, проводимый экспертом. Эксперт вводит в систему обучающую выборку (набор объектов с уже известными классами), на основе которой строится классификационная модель. В текущей версии системы классификация осуществляется с помощью разделяющих функций, так что построение модели сводится к вычислению разделяющих функций по обучающей выборке. Разделяющие функции по набору значений атрибутов объекта выдают ответ о его принадлежности к соответствующему классу. 59

После обучения системы можно классифицировать объекты неизвестного класса с помощью реализованного в системе Классификатора и получать результат классификации с помощью подсистемы вывода данных. Поскольку в большинстве современных информационных систем в качестве промежуточного формата представления данных используется язык XML, используемый также в качестве стандарта для интеграции различных систем, то он был для представления данных описываемой системы. Это делает подсистемы ввода и вывода универсальными по данным. Статья имеет следующую структуру. В разделе 2 описывается архитектура системы – набор интерфейсов и подсистемы, реализованные на базе описанных интерфейсов. В разделе 3 описана подсистема ввода данных, позволяющая получать исходные данные для классификации как из внешних систем, так и с помощью ручного ввода данных в систему. Подсистема обучения, в которой производится построение разделяющих функций, обсуждается в разделе 4. Раздел 5 содержит описание подсистемы классификации для определения класса пробы. Результат классификации выводится с помощью подсистемы вывода, описанной в разделе 6. В разделе 7 рассматриваются представления данных в формате XML. Раздел 8 посвящен требованиям к аппаратуре, необходимой для нормальной эксплуатации системы, а также составу предустановленного программного обеспечения. В заключительном разделе 9 приводятся статистические данные, полученные в ходе эксплуатации системы для классификации химических проб в лаборатории химического предприятия.

2. Архитектура системы Система состоит из следующих подсистем: классификатор, подсистема обучения, подсистема ввода и подсистема вывода (Рис. 1).

Рис.1. Подсистемы, входящие в состав системы

60

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

Рис. 2. API и GUI для реализации подсистем В системе определены процессы настройки, обучения и, собственно, классификации. Настройка системы, выполняемая системным программистом, позволяет изменить алгоритм классификации, и на его основе с использованием интерфейсов программируются подсистемы обучения и классификации. Обучение системы производится экспертом, который определяет форматы ввода в систему обучающей выборки и вывода результатов. При необходимости эксперт обращается к системному программисту для реализации интерфейсов с приборами. Для обеспечения модификации указанных подсистем при изменении требований к системе классификации разработан и реализован набор прикладных интерфейсов. В системе предусмотрены следующие интерфейсы: 1.

Интерфейсы для реализации и модификации подсистемы ввода данных: a. задание объектов в системе через пользовательский интерфейс; b. опции настройки пользовательского интерфейса; c. загрузка объектов в систему из внешнего файла; d. выгрузка объектов из системы во внешний файл; e. загрузка параметров из внешнего устройства в поле объекта; f. задание в системе дерева классов; 61

g. добавление в системе узлов дерева классов; h. добавление селекторов в дереве классов; i. задание объекта неизвестного класса. 2. Интерфейсы для реализации и модификации подсистемы обучения: a. загрузка в подсистему обучения обучающей выборки; b. загрузка в подсистему обучения дерева классов; c. выгрузка поддерева дерева классов по заданным параметрам и селекторам переходов между узлами дерева; d. выгрузка результата обучения; e. интерфейсные выходы в подсистему ввода данных (необходимо для интерактивных алгоритмов классификации); f. выгрузка дерева классов. 3. Интерфейсы для реализации и модификации подсистемы классификации: a. загрузка в подсистему классификации дерева классов; b. загрузка в подсистему классификации результатов обучения; c. загрузка объекта неизвестного класса; d. интерфейсные выходы в подсистему ввода данных (необходимо для интерактивных алгоритмов классификации); e. выгрузка результата классификации; f. добавление объекта в обучающую выборку. 4. Интерфейсы для реализации и модификации подсистемы вывода данных: a. опции настройки пользовательского интерфейса; b. выгрузка объектов из системы во внешний файл; c. получение результата классификации. На рис. 3 в качестве примера приведено полное описание интерфейса «Выгрузка поддерева дерева классов по заданным параметрам и селекторам переходов между узлами дерева».

using System; using System.Collections.Generic; using System.Text; namespace Tsa.Opc { public interface ITsaOpcDataSource { /// /// Функция возвращает массив дочерних элементов для элемента с полным именем fullName. /// Корневой элемент один и его имя "". /// При передаче fullName равного null, должен возвращатся массив, /// состояший из одного корневого элемента. 62

/// IBrowseTreeSpaceItem[] Browse(string fullName); /// /// Функция возвращает сам элемент с полным именем fullName. /// Корневой элемент один и его имя "". /// IBrowseTreeSpaceItem BrowseItem(string fullName); /// /// Получить данные по признаку fullname. /// Метод должен вернуть значения, которые входят в интервал [startTime:endtime] плюс одно /// значение, которое "ниже", чем startTime, и одно значение, которое "выше", чем endTime /// }

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

public interface IBrowseTreeSpaceItem { string Name { get;} string FullName { get;} }

}

Рис. 4. Подсистема ввода.

IBrowseItemProperty[] Properties { get;}

public interface IBrowseItemProperty { Type ValueType { get;} int PropertyId { get;} string Name { get;} string Description { get;} object Value { get;} }

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

3. Подсистема ввода данных

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

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

64



структурирование всех журналов в удобную для использования иерархию;



регистрация проб, поступивших на испытание;



выбор значения параметра из заранее заданного списка;



автоматический расчет параметров по заданным формулам (математические формулы – результатом является число, логические формулы – результатом является, например, “соответствует/не соответствует норме”);



выполнение расчетов с заданной точностью;



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



быстрый поиск нужного эксперимента, по любому параметру;



быстрая сортировка записей экспериментов по любому параметру (по возрастанию/убыванию);



выполнение параллельных испытаний с последующей консолидацией результатов;



поверка приборов;



хранение информации о том, кто выполнил эксперимент;



выгрузка/загрузка одного журнала (или всех журналов) с возможностью отправки по электронной почте или записью на внешний носитель;



возможность ввода и ведения атрибутов журнала (ФИО ответственного за методику сотрудника, список приборов, используемых в определении показателей для журнала и т.д.);



разделение прав доступа пользователей на чтение/запись/изменение данных в электронном журнале;



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

Рис. 5. Экранная форма с введенными вручную данными.

Ручной ввод данных в систему осуществляется по заранее заданным шаблонам представления объектов (Рис. 5.). Чтобы избежать ошибок ввода для обучающей выборки (Рис. 6), в систему встроен механизм проверок данных на правильность и целостность (например, если агрегатное состояние пробы питьевой воды выбрано как «лед», то температура пробы не может быть +5ºС). Некоторые признаки объектов могут рассчитываться по формулам на основе введенных значений других признаков, полученных экспериментальным путем. Рис. 6. Экранная форма работы с внешними данными: загрузка и выгрузка обучающей выборки. 65

66

4. Подсистема обучения

5. Классификатор

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

Классификатор представляет собой подсистему, реализующую применение экспертных и экспериментальных знаний для основной цели системы – классификации пробы неизвестного класса (Рис. 9). Подробно алгоритм классификации описывается в [1, 2, 3].

Подсистема обучения Обеспечение внешних взаимодействий

Классификатор

Обеспечение внешних взаимодействий

Построение разделяющих функций

Определение подмножества потенциальных классов

Уточнение подножества потенциальных классов по расстоянию Журавлева

Вычисление разделяющих функций для потенциальных классов

Рис. 7. Подсистема обучения. Подробно алгоритм обучения описывается в [1, 2, 3]. Для пользователя системы работа подсистемы обучения практически не видна. Пользователь запускает функцию «Обучение», и по окончанию обучения системы он видит в окне отчетов работы системы сообщение об окончании обучения (Рис. 8).

Рис. 9. Подсистема Классификатор. Для начала работы с классификатором пользователь должен ввести объект, задать значения признаков и оставить класс объекта пустым, затем запустить операцию классификации и дождаться результата в нижней части окна системы (Рис. 10).

Рис. 8. Запуск и выполнение обучения.

Рис. 10. Классификация неизвестной пробы. 67

68

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

Обеспечение внешних взаимодействий

Вывод данных о пробе в паспорт качества пробы

Вывод результата классификации

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

Рис. 12. Модель поступления данных в систему. Рис. 13. Шаблон для хранения информации об объектах в формате DTD.

7. Представление данных На Рис. 12 представлена схема ввода данных в систему. Подробно ввод данных описан в разд. 3. 69

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

то он был использован для представления данных описываемой системы. Это делает подсистемы ввода и вывода универсальными по данным. Для наиболее эффективного хранения информации, а также для оптимальной интеграции с разнородными источниками данных был разработан специальный шаблон хранения информации. Для описания формата хранения был использован стандарт DTD – Document Type Definition (Рис. 13). Данный стандарт широко известен и часто используется при работе со средствами XML, несмотря на развитие новых способов описания метаданных XML. В рамках нашей системы допустимым признается корректно сформированный XML файл, не противоречащий данному определению типа документа. - - Грунтовые воды - Питьевая вода - Природная вода - Открытые источники - Дождевые воды - Питьевая - Особо очищенная - Сточные воды - Промышленные отходы -

Бытовые отходы - Питьевая вода - Дождевые воды - C1 Рис. 14. Пример описания словаря классов в формате XML. Контейнер верхнего уровня – это объект, который в рамках системы может быть одним из различных функциональных элементов в зависимости от того, какому классу он принадлежит. Класс принадлежности объекта определяется в соответствии с вложенным контейнером. Единицей, хранящей информацию, является набор атрибутов, которые, согласно приведенному определению типа документа, могут быть произвольного типа и в любом количестве. На Рис. 14 представлен пример этого формата – XML-файл, описывающий словарь классов.

8. Технические характеристики системы Система реализована на языке С# в среде VisualStudio. Данные в системе представлены в формате XML, что обеспечивает дополнительную универсальность в использовании данных из каких-либо внешних систем. Реализация системы состоит из приблизительно 5500 строк, из которых 3500 строк – инфраструктура системы в ядре, остальной код – реализация системы для решения задачи классификации химических проб. Требования к аппаратуре: Для работы с системой рекомендуется следующая конфигурация рабочей станции: Pentium III, тактовая частота не менее 500МГц, свободное место на диске (HDD) не менее 500Мб, оперативная память не менее 256Мб. Минимальная конфигурация: Celeron, тактовая частота 200МГц, свободное место на диске 150Мб, оперативная память 64Мб. Требования к системному ПО: Для работы оператора с системой рекомендуется следующая конфигурация программного обеспечения (ПО) для рабочей станции: Microsoft Windows 2000, Microsoft Internet Explorer 5.5, Microsoft Office 2003, XP. 71

72

Минимальная конфигурация ПО для рабочей станции: Microsoft Windows 98, Microsoft Internet Explorer 4.0.

9. Результаты экспериментальных расчетов В Табл. 1 приведены некоторые результаты проведения экспериментов, полученные в ходе тестирования системы.

Приемлемое число объектов обучающей выборки (при условии нормального распределения значений атрибутов) в зависимости от количества классов приведено на Рис. 15. число объектов обучающей в ыборки 800

число число число объектов объектов число объектов обучающей обучающей объектов количество выборки обучающей выборки количество обучающей количественных выборки для для 5-х для 7-х классов выборки признаков 3-х классов классов классов

700 600 500 400 300

0

0

0

0

0

0

200

1

0

1

14

67

70

100

2

8

2

24

87

84

3

16

3

22

86

92

4

25

4

25

94

120

5

39

5

39

89

140

6

59

6

41

110

144

7

87

7

38

98

128

8

120

8

35

101

129

9

160

9

34

102

148

10

220

10

36

89

133

11

269

11

32

92

152

12

314

12

33

95

146

13

420

13

34

101

178

14

560

15

700

0 1

3

5

7

9

11

13

15

Кол-во классов

Рис. 15. График зависимости приемлемого числа данных объектов обучающей выборки от числа классов. Кол-во классов-3

Число объектов 200 обучающей 180 выборки 160

Кол-во классов-5 Кол-во классов-7

140 120 100 80 60 40 20 0 Количество признаков

Таблица 1. Результаты проведения экспериментов

Рис. 16. График зависимости приемлемого числа данных объектов обучающей выборки от количества признаков. 73

74

Приемлемое число объектов обучающей выборки (при условии нормального распределения значений атрибутов) в зависимости от количества признаков для разного числа классов приведено на рис. 16. Литература [1] Маракаева Г.Т. "Применение методов выявления закономерностей для классификации химических соединений", Сборник статей ИСП РАН, 2006 [2] Маракаева Г.Т. "Использование подходов Data Mining в развитии систем ЛИМС", ежемесячный научно-технический и производственный журнал "Автоматизация в промышленности", №12, 2006 [3] Маракаева Г.Т. "Обоснование правильности работы алгоритма классификации", тезисы к докладу на международной московской конференции Ломоносов 2006, МГУ, 2006.

75

История и актуальные проблемы темпоральных баз данных Б.Б. Костенко, С.Д. Кузнецов

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

В русскоязычной литературе вместо термина «темпоральные базы данных» иногда применяется термин «временные базы данных». Но поскольку, вопервых, в этой области отсутствует устоявшаяся русскоязычная терминология и, во-вторых, при использовании первого термина, являющегося калькой английского термина temporal database, не требуется дополнительное уточнение ударения, в этой статье будет использоваться именно этот термин. 2 За исключением специально оговоренных случаев в этой статье речь будет идти о реляционной модели данных (и ее темпоральных расширениях). Кроме того, здесь не проводится различия между реляционной моделью данных в классическом смысле и моделью данных языка SQL, и используются термины, принятые в мире SQL-ориентированных баз данных. 77

зависимость от времени, так как когда-то нам (или системе) стало известно, что такая аксиома существует. Кроме того, есть вероятность, что в будущем аксиома будет опровергнута, или на условия ее применимости будут наложены определенные ограничения; поэтому нельзя уже будет рассматривать ее как некоторую абсолютную истину, верную во всех ситуациях и в любой момент времени3. Темпоральные базы данных – это базы данных, хранящие темпоральные данные. Однако эти базы данных и содержащиеся в них данные могут рассматриваться как темпоральные только в том случае, если известно правило интерпретации временных меток и интервалов для конкретной системы управления базами данных (СУБД). Чтобы определить, является ли рассматриваемая СУБД темпоральной в полном смысле этого слова, необходимо понять, можно ли отдельно выделить и специальным образом интерпретировать данные атрибута «время». В категорию темпоральных СУБД не будут попадать обычные реляционные СУБД, в которых поддерживаются связанные со временем типы данных, но интерпретацией и связью данных (или событий) между собой с учетом времени приходится заниматься разработчику. В «настоящей» темпоральной СУБД учитываются специфическая природа времени и изменчивость данных с течением времени. Специальные публикации на русском языке, посвященные тематике темпоральных баз данных, почти полностью отсутствуют. В данной обзорной статье невозможно сколько-нибудь полно охватить все направления исследований нескольких последних десятилетий, поэтому в ней рассматриваются только ключевые этапы развития данной области исследований, а также наиболее актуальные исследования и разработки, известные в настоящее время. В начале статьи кратко представлена история области исследований темпоральных баз данных и перечислены наиболее значимые поворотные моменты. Затем излагаются основные понятия и термины, идеи и подходы, 3

Если пойти еще дальше, то можно даже сказать, что результаты любых вычислений, по сути, тоже являются темпоральными данными, так как связаны со временем. Например, представим, что определенное решение принимается на основе целочисленного округления значения некоторого вещественного выражения. Если система некоторое время округляет 0.5 до 0, а потом – до 1, то мы можем получить разные результаты на одних и тех же исходных данных, то есть F(C) ≠ F(C), где C – константа. Для формально корректной записи подобного неравенства требуется введение дополнительного аргумента – момента вычисления, и тогда получится абсолютно корректное выражение F(C, t1) ≠ F(C, t2). Данный пример может показаться несколько искусственным, но он демонстрирует, что время является неотъемлемым атрибутом любых данных, когда речь идет о практической работе с конкретной системой, а не лишь о теоретическом ее исследовании. 78

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

2. Краткая история История систем реляционных баз данных насчитывает более трех десятилетий. Примерно на 10 лет позже появились идеи реализации систем управления темпоральными базами данных, до сих пор не воплощенные полностью ни в одной реализации крупных коммерческих СУБД4. Принято считать, что впервые идеи управления темпоральными данными появились в работе Якова Бен-Зви (Jacob Ben-Zvi) в 1982 г. [BZ82], но эта работа не получила широкой известности, хотя и предвосхитила многие последующие исследования в области темпоральных баз данных. Позже, в 80-е гг. начали появляться работы по темпоральной логике и использованию данных, зависимых от времени, их представлению внутри системы и визуализации для пользователя. С тех пор предлагались различные модели, создавались прототипы систем темпоральных баз данных ([Böh95]). Одним из ключевых периодов в области исследований темпоральных баз данных, временем ее «официального» представления можно считать 1992– 1993 гг. В это время сначала Ричард Снодграс (Richard Snodgrass) высказал идею о возможном темпоральном расширении стандарта языка запросов к реляционным базам данных SQL-92, а затем был проведен семинар «ARPA/NSF International Workshop on an Infrastructure for Temporal Databases», продемонстрировавший заинтересованность научного сообщества в создании и использовании темпорального расширения стандарта языка запросов к базе данных ([AJS95]). После этого семинара была образована комиссия по созданию спецификации подобного языка, в которую вошли Ричард Снодграс, Илсу Ан (Ilsoo Ahn), Гэд Ариав (Gad Ariav), Дон Бэтори (Don Batory), Джеймс Клиффорд (James Clifford), Картис Дайрсон (Curtis E. Dyreson), Кристиан Йенсен (Christian S. Jensen), Рамес Элмасри (Ramez Elmasri), Фабио Гранди (Fabio Grandi), Вольфганг Кафер (Wolfgang Kaefer), Ник Клайн (Nick Kline), Кришна Кулкарни (Krishna Kulkarni), Тинг Клифф Леунг (Ting Y. Cliff Leung), Никос Лоренцос (Nikos Lorentzos), Джон Роддик (John F. Roddick), Эрай Серев (Arie Segev), Майкл Су (Michael D. Soo) и Суринараяна Срипада (Surynarayana 4

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

M. Sripada). После нескольких лет плодотворной работы в начале 1994 года появилась первая предварительная версия спецификации языка, а на основе полученных замечаний в сентябре того же года была выпущена окончательная спецификация языка запросов TSQL2 [SAAB95]. Одновременно со спецификацией языка запросов TSQL2 были распространены комментарии [SAAB95], в которых объяснялись решения, принятые в ходе подготовки языка запросов, а также предоставлялись примеры, и рассматривались возможные пути реализации данного языка на основе существующих СУБД. Позднее эти комментарии, которые, по сути, не являлись частью спецификации языка, стали использоваться для сравнения TSQL2 с другими предлагаемыми темпоральными моделями и языками запросов к ним.

2.1. Принятие стандарта и коммерческие реализации Представленная спецификация языка TSQL2 позволяла делать оптимистичные прогнозы относительно возможности расширения спецификации языка SQL92 новыми конструкциями и одновременной интеграции темпоральной модели в реляционную модель данных. Разные члены сообщества исследователей темпоральных баз данных работали над переносом конструкций и логики языка TSQL2 в язык SQL3 (позднее названный SQL:1999). Первым шагом стало добавление в 1995 году проекта седьмой части спецификации языка SQL3, названной SQL/Temporal. В 1996 году два предложения [SBJ96a] и [SBJ96b] (а также их дополнения [Sno96] и [Sno97]), описывающие добавление действительного, или модельного (valid) и транзакционного (transaction)5 времен к стандарту SQL-92, были единодушно поддержаны в ANSI и переданы в ISO. В это же время Андреас Стейнер (Andreas Steiner) и Михаель Бехлен (Michael Н. Böhlen) создали прототип TimeDB, поддерживающий возможность работать и с действительным, и с транзакционным временами ([Tim07]). Система являлась прослойкой6 между интерфейсом пользователя и одной из коммерческих СУБД, обеспечивая поддержку темпоральных конструкций путем их преобразования в обычные реляционные структуры и обратно. Позднее разработчики пытались позиционировать TimeDB как коммерческий проект, но, по-видимому, не достигли в этом успехов. Многие исследователи были убеждены, что окончательное принятие стандарта и появление расширений для поддержки темпоральных баз данных в развитых коммерческих СУБД должны были произойти уже в самом начале XXI века. Однако седьмая часть стандарта так и осталась на бумаге. Более того, несколько лет назад работы над стандартом SQL/Temporal были вообще 5

Эти и другие термины будут более подробно рассмотрены и разъяснены в разд. 4. 6 Подробнее об этом см. разд. 7. 80

прекращены (или приостановлены на неопределенный срок) [Jcc07]. Производители СУБД также не добавили в свои продукты полноценную темпоральную поддержку. Кристофер Дейт (C. J. Date) в [DDL02] считает целесообразным введение курса по работе с темпоральными данными в рамках программы подготовки специалистов (и сам читает подобный курс в одном из университетов), но соглашается, что для производителей сейчас более актуальными являются другие задачи, связанные, например, с расширением функциональности для поддержки электронного бизнеса и т.п. Однако стоит отметить, что некоторые производители коммерческих СУБД уже обращают внимание на проблему поддержки работы с темпоральными данными в своих системах, предоставляя определенные дополнительные возможности как для администраторов, так и для пользователей. Но из-за отсутствия стандарта нет ни единого подхода, ни одинаковой поддерживаемой функциональности. Более того, системы в явном виде не позиционируются как поддерживающие работу с темпоральными данными, поэтому невозможно говорить даже о наличии стандарта de facto. Между тем, начиная уже с 2000 года, часть исследователей темпоральных баз данных обратила внимание на XML-данные, для которых стандарт языка запросов еще только вырабатывался. Необходимость разработки новых интерпретаторов запросов и гибкость структур языка давали некоторым разработчикам надежду на реализацию темпоральной XML-СУБД. Однако текущая ситуация напоминает ту, которая сложилась в области реляционных баз данных: предложено несколько моделей и созданы прототипы, но все это осталось пока лишь иллюстрацией или инструментом для решения конкретной проблемы и не может претендовать на то, что со временем будет стандартизовано7.

3. Появление области исследований темпоральных баз данных В предыдущем разделе была представлена краткая история появления и развития области исследований темпоральных баз данных. Далее будут даны определения основных понятий, описаны наиболее важные проблемы, с которыми сталкивались и сталкиваются разработчики при создании темпоральных баз данных. Но вначале кратко ответим на один из основных вопросов, почему же возникла потребность в расширении стандарта языка SQL, и почему возникла подобная область исследований? Одной из предпосылок создания темпорального расширения языка SQL явилось то, что почти все приложения, использующие реляционные базы данных, являются темпоральными по своей сути. В базах данных хранятся данные, изменяющиеся с течением времени. С другой стороны, многие 7

Здесь речь идет об общем стандарте, а не какой-нибудь специальной функциональности для определенной прикладной области. 81

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

4. Основные понятия В данном разделе будут представлены основные понятия, используемые в области темпоральных баз данных. Начнем с базового понятия – линия времени.

4.1. Линии времени В повседневной жизни человек чаще всего не задумывается, что использует только одну линию времени. События могли уже произойти в прошлом или только планируются в будущем, но время всегда измеряется согласно одним часам. С другой стороны, в базе данных может сохраняться информация о событиях и интервалах времени, соответствующих различным представлениям и связям. Если обработкой подобных данных занимается сам пользователь, то используемый тип времени можно назвать временем, определяемым пользователем. Его отличительным признаком служит отсутствие интерпретации со стороны СУБД, так как обработка данных, связанных со временем, полностью возлагается на пользователя. Фактически, все современные СУБД обеспечивают поддержку подобной разновидности времени, например, с помощью введения специальных типов данных DATA или TIMESTAMP. Если рассматривать данные, представленные в базе данных, как некоторое отражение текущего состояния действительности для моделируемого мира, то каждая запись может восприниматься как некоторый факт, который является истинным в определенный момент или интервал времени. При переходе к темпоральной базе данных для каждого факта можно указать тот промежуток времени8, когда этот факт являлся истинным в моделируемом мире, представленном в базе данных. Подобное представление времени, когда с 8

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

данными связывается промежуток времени их актуальности (с точки зрения моделируемого мира), называется модельным, или действительным (valid) временем. Его значения можно сравнить с показаниями часов моделируемого мира. Поскольку довольно часто в базе данных отражается именно реальный мир, могут быть заданы соотношения между значениями времени реального мира и представленной в базе данных моделью. Отметим, что значениями данного типа времени могут быть моменты времени как в прошлом, так и в будущем. Кроме того, эти значения могут изменяться, то есть истинность факта в определенные моменты времени может приниматься или отклоняться. Другим типом линии времени, который рассматривается исследователями темпоральных баз данных, является транзакционное время. В любой СУБД каждой записи базы данных можно сопоставить тот промежуток времени, когда данная запись была представлена в базе данных, т.е. промежуток времени между моментами добавления записи и ее удаления из базы данных. При этом отметим, что операция обновления, которая действительно вносит изменения в запись, понимается как составная операция удаления старой записи и добавления новой. Очевидно, что значения транзакционного времени не могут относиться к будущему. В подавляющем числе СУБД транзакционное время используется для работы с блокировками, журналом для восстановления системы. В некоторых системах администраторы даже могут использовать специальные расширения языка SQL, позволяющие получить доступ к транзакционному времени и истории изменений записей в базе данных. сотрудник ALAN BOB

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

з/плата

ALAN

500

BOB

300

BOB

400

з/плата

BOB

300

BOB

500

BOB

400

500

транзакционное время с 20 декабря 2005 с 3 марта 2005 по 27 января 2006 с 28 января 2006 по 5 февраля 2006 с 6 февраля 2006

Рис. 3. Таблица с поддержкой транзакционного времени

з/плата 500 400

Рис. 1. Таблица без темпоральных расширений

сотрудник

табельный номер ALAN

табельный номер ALAN

з/плата

BOB

300

BOB

500

с 1 февраля 2006

BOB

400

с 1 февраля 2006

500

действительное время с 1 января 2006 с 1 марта 2005 по 31 января 2006

транзакционное время с 20 декабря 2005 с 3 марта 2005 по 27 января 2006 с 28 января 2006 по 5 февраля 2006 с 6 февраля 2006

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

действительное время с 1 января 2006 с 1 марта 2005 по 31 января 2006 с 1 февраля 2006

9

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

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

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

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

4.2. Интервальное и точечное представления В предыдущем подразделе при обсуждении действительного времени, говорилось, что существует некоторый интервал, в котором определенный факт являлся истинным. Это так называемое интервальное представление. Однако можно рассматривать отдельный момент времени и все факты, которые были истинны в этот конкретный момент (рис. 6). действительное время ALAN BOB

ALAN 500 400 300

01.03.2005

03.03.2005

28.01.2006

01.02.2006

06.02.2006

Рис. 5. Связь линий времени для сотрудника ALAN Исследователи темпоральных баз данных обычно используют один из данных типов времени или оба одновременно. В некоторых работах предлагаются и другие линии времени10, хранение значений которых может быть интересно пользователю, но все они могут быть сведены к одному из рассмотренных типов, возможно, через дополнительные отношения. Говоря о линиях времени, необходимо ввести еще один термин – гранулярность, которая показывает, насколько близкие моменты на оси времени все еще будут отличимыми друг от друга. Например, возможно, что для данных о заработной плате сотрудника достаточно разбиения по дням, но для транзакционного времени может быть недостаточно даже разбиения по секундам, если в СУБД возможна более частая фиксация транзакций. В общем случае с каждой линией времени может быть еще связан некоторый календарь, который определяет диапазоны значений, гранулярность, 10

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

19.12.2005 20.12.2005 … 31.12.2005 01.01.2006 … 28.02.2005 01.03.2005 02.03.2005 03.03.2005 … 15.09.2005 … 27.01.2006 28.01.2006 … 31.01.2006 01.02.2006 … 05.02.2006 06.02.2006 … сейчас

100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100

300 300 300 300 300 300 300 300 300 300 400 400 400 400 400 400

транзакционное время ALAN BOB 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100 100

300 300 300 300 300 500 500 500 500 500 500 400 400 400

Рис. 6. Точечное представление и срезы на линии времени Здесь говорится о представлении времени с точки зрения пользователя, то есть тех условных моделях, в рамках которых могут формулироваться запросы и возвращаться их результаты. При использовании любого из этих представлений истинность фактов не меняется, но в случае точечного представления мы получаем срез всех фактов на какой-то конкретный момент времени, а для интервального представления нас интересует определенный факт и периоды его истинности. Если говорить об обычной реляционной модели, то она опирается на точечное представление для актуального 86

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

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

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

сканер

прослойка

ошибка

парсер

метаданные

результат

транслятор

фильтр

SQL запрос Q’

СУБД

Рис. 7. Общий вид многоуровневой архитектуры темпоральной СУБД 11

В данной статье основное внимание уделяется именно реляционным темпоральным базам данных. О других вариациях будет упомянуто в разд. 6. 87

Отсутствовала и соответствующая потребность со стороны пользователей. Поэтому вскоре разработчики стали рассматривать различные способы дополнения и расширения обычных реляционных СУБД поддержкой темпоральной модели данных12. Почти все такие способы сводились к созданию некоторого функционального блока, отвечающего за разбор темпоральных запросов, подмену их некоторыми реляционными вычислениями, а потом обратное преобразование в требуемое темпоральное представление для возвращения результатов пользователю. Основным отличием был уровень «вмешательства» в реляционную СУБД, а также степень интеллектуальности данного блока темпоральных преобразований (рис. 7). Сравнение различных вариантов реализации промежуточного слоя представлено, например, в [TJS98]. Рассмотрим три крайних случая: преобразование на уровне ядра реляционной СУБД, преобразование на уровне пользовательского приложения и использование независимого промежуточного proxy-уровня. Первый способ предоставляет максимум возможностей по расширению синтаксиса языка баз данных, обеспечению различных проверок, а также оптимизации. Он также обеспечивает полную прозрачность для всех пользовательских приложений, а возможно, и для администратора БД. Однако он доступен только разработчикам СУБД. В отличие от простого использования приложением реляционной СУБД для работы с темпоральными данными второй способ предполагает выделение некоторых модулей или библиотеки (в пользовательском приложении), отвечающих за преобразование именно темпоральных запросов. То есть основное приложение использует некоторую темпоральную абстракцию, а не реляционную БД в чистом виде, а потом интерпретирует результаты запросов. Подобная абстракция (пусть и на уровне приложения) позволяет сократить число ошибок и отделить бизнес-логику приложения от технической составляющей хранения данных13. В [Sno99] подробно описано, как можно создавать темпоральные приложения в рамках реляционной СУБД. Третий способ подразумевает создание между пользовательским приложением и СУБД некоторого промежуточного «черного ящика» (будем называть его proxy-уровнем), который может быть реализован в виде драйвера, сервиса, внешней библиотеки и т.п. Для пользовательского приложения этот proxy-уровень должен работать как темпоральная СУБД. С другой стороны, для СУБД этот proxy-уровень является обычным реляционным приложением. Поэтому proxy-уровень оказывается прозрачным как для пользовательского приложения, так и для СУБД, а также не требует 12

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

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

5.2. Язык запросов к темпоральной базе данных Для работы с темпоральными базами данных необходимо было разработать язык запросов к ним, который должен был бы стать расширением языка запросов SQL к реляционным базам данных. Рассмотрение языка запросов начнем с конструкций выборки, предложенных авторами языка TSQL2 (SQL/Temporal). Выше говорилось о темпоральных базах данных, однако реляционная модель предполагает, что данные хранятся в таблицах, и база данных состоит из набора таких таблиц. Поэтому уточним понятия. Во-первых, поскольку практически любая база данных содержит данные, связанные с промежутками времени, ее можно было бы назвать темпоральной. Однако, говоря о темпоральной СУБД, подразумевают, что интерпретацией подобных данных занимается сама система, и поэтому принято считать, что темпоральная база данных – это база данных, содержащая связанные со временем данные, интерпретацией которых занимается СУБД, являющаяся, таким образом, темпоральной СУБД14. С другой стороны, под управлением темпоральной СУБД вполне может находиться обычная реляционная база данных. Более того, для части таблиц темпоральная поддержка может быть включена, а для

14

Данное определение не противоречит определениям, приведенным ранее, но вполне конкретизирует пару «темпоральная база данных и соответствующая СУБД». 89

других таблиц – нет15. Поэтому далее будем рассматривать отдельную таблицу, на время забывая о возможных ее связях с другими таблицами. При построении модели языка запросов к темпоральной базе данных ставились следующие цели. Во-первых, при переходе к темпоральной модели желательно расширить все три компонента модели данных: структуру данных, операции и ограничения целостности. Во-вторых, любая корректная конструкция в исходном языке запросов должна остаться корректной в новом языке, и семантика этих конcтрукций должна остаться прежней; например, результат, возвращаемый запросом, должен быть таким же. То есть необходимо обеспечить восходящую совместимость языка запросов и базы данных. Кроме того, желательно обеспечить темпоральную восходящую совместимость: необходимо, чтобы после добавления в систему темпоральной поддержки все унаследованные конструкции продолжали работать так же, как и раньше. Из этого следует, что все существующие приложения не должны почувствовать переход от обычной реляционной СУБД к темпоральной СУБД ([BBJ+97]). Более того, последующее добавление темпоральной поддержки в какую-нибудь конкретную таблицу не должно отразиться на корректности выполнения запросов. С другой стороны, подобное добавление должно позволить использовать темпоральные запросы в новых программах, заметно облегчая работу программистам и администраторам системы. Рассмотрим таблицу, содержащую информацию о заработной плате сотрудников. До добавления темпоральной поддержки таблица содержала только актуальную информацию (на текущий момент времени)16. В таком случае у приложения имеется возможность узнать текущее значение любых элементов данных, но предыдущее значение будет потеряно после любого изменения. После удаления записи например вообще невозможно будет сказать, , сколько получал данный сотрудник перед увольнением. Такая ситуация существует при использовании традиционной реляционной модели (рис. 8). Предположим, что позже было принято решение о необходимости хранить историю значений заработной платы сотрудников. Решить это можно было бы несколькими путями. Во-первых, можно создать специальную таблицу с историей зарплаты, но это могло бы быть достаточно странным, так как уже есть таблица «заработных плат». Более того, пришлось бы модифицировать код приложения, чтобы при удалении и изменении значений происходило автоматическое обновление данных и во второй таблице. 15

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

новые темпоральные запросы, которые позволят узнать историю изменений (рис. 9). Какие же запросы могут быть сформулированы к таблице с темпоральной поддержкой? Во-первых, это запрос значений на какой-нибудь момент времени в прошлом, то есть создание среза истинности фактов на произвольную дату. Например, для обычного реляционного запроса «какую зарплату сейчас получает каждый из сотрудников?» можно легко сформулировать его темпорального двойника «какую зарплату получал каждый из сотрудников в указанную дату?» В этом случае результат запроса останется в рамках реляционного представления. С другой стороны, вполне естественным оказывается запрос «когда и какую зарплату получал каждый из сотрудников?». Здесь уже в результатах запроса появляется линия времени. Один из традиционных способов представления подобных результатов опирается на интервальное действительное время, то есть к обычному реляционному представлению результатов добавляется еще один столбец, содержащий интервалы истинности фактов. Алгоритм формирования результатов подобных запросов можно упрощенно представить следующим образом: для каждого момента времени17 вычисляется реляционный подзапрос «какую зарплату получает каждый из сотрудников», после чего к общему результату добавляются результаты этих подзапросов с учетом интервалов истинности. Подобная семантика «последовательной» интерпретации реляционных запросов называется последовательной (sequenced valid semantics), см. рис. 10. Однако на основе этой семантики невозможно сформировать запрос, который требует «сравнения» нескольких последовательных моментов времени. К таким запросам относится большинство запросов, включающих агрегационные функции «во времени», например, «вывести среднюю заработную плату сотрудника за все периоды времени» (отметим, что результат будет представлен обычной реляционной таблицей) или «вывести периоды, когда на оплату труда сотрудников уходила максимальная сумма». Предусмотреть все подобные типы запросов невозможно, и также нельзя ограничивать выразительные возможности языка, поэтому была предложена конструкция запросов произвольного доступа к темпоральным данным (NonSequenced Queries), которые предоставляют возможность самостоятельно сформулировать необходимый запрос, накладывая ограничения на системный темпоральный столбец18. См. рис. 11.

Рис. 8. Работа с таблицей без темпоральной поддержки

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

17

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

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

5.3. Представление результатов темпоральных запросов Рис. 10. Обработка "последовательных" запросов к темпоральной таблице

Рис. 11. Обработка "произвольных" запросов к темпоральной таблице Таким образом, при наличии темпоральной поддержки в системе можно выделить четыре уровня использования запросов (для конкретной таблицы): 1 – темпоральная поддержка для таблицы отсутствует, 2 – использование реляционных запросов к таблице с темпоральной поддержкой, 3 – использование последовательных запросов и 4 – использование произвольных темпоральных запросов. Подобная классификация верна как для таблиц с поддержкой действительного времени, так и для тех, для которых поддерживается транзакционное время. Поскольку эти линии времени являются ортогональными и независимыми, в системе с темпоральной 93

Выше уже упоминались два подхода к представлению информации в темпоральной базе данных: интервальный, когда принимается во внимание период истинности факта, и точечный, когда для каждого отдельного момента времени рассматриваются все факты, истинные в этот момент. При реализации темпоральной СУБД и проектировании языка запросов требуется выбрать один из этих вариантов представлений. При хранении данных в базе данных наиболее компактным является интервальное представление. При представлении результатов запросов также многое говорит в пользу интервального представления19. Но при формулировке многих запросов удобнее сравнивать моменты времени, а не оперировать интервалами истинности отдельных фактов, поэтому точечное представление получает значительное преимущество. Операции над множествами очень удобны для теоретических выкладок и формализации, но трудно реализуемы в системе при значительном объеме данных. Поэтому интервалы времени принято разделять на такие подинтервалы, чтобы для каждого факта они не пересекались, но дополняли друг друга до исходного интервала, а любые два интервала разных фактов либо не пересекались, либо совпадали. При таком представлении истинность фактов не будет меняться ни для одного из получившихся интервалов, что позволит, например, корректно использовать полный вложенный перебор по интервалам и фактам при получении результата запросов. После получения результата в виде набора интервалов истинности для каждого факта необходимо выполнить обратную процедуру – объединение пересекающихся или примыкающих друг к другу интервалов. Два данных преобразования называются распаковкой и упаковкой. Эти операции могут применяться и во 19

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

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

5.4. Специальное значение «сейчас» Слово «сейчас» означает «в настоящее время, в данный момент». В запросах на языке SQL довольно часто используются конструкции CURRENT_TIMESTAMP, CURRENT_DATE и CURRENT_TIME, которые заменяются соответствующими константами в момент выполнения запросов, поэтому в самой базе данных хранятся лишь конкретные значения дат и времени. Так как язык запросов к темпоральной базе данных является расширением языка SQL, данные конструкции в нем также могут использоваться как синонимы «динамических» констант. Однако для работы с фактами, которые истинны в настоящий момент, но могут меняться с течением времени, необходимо использовать дополнительное специальное значение СЕЙЧАС. Оно используется при задании верхней границы интервала истинности факта, хранимого в таблице с темпоральной поддержкой ([CDI+97]). Пусть в базе данных хранится информация о периоде работы сотрудника в компании. Тогда до 2 апреля для сотрудника, пришедшего на работу 1 апреля, промежутком времени его работы в компании является один день 1 апреля. На следующий день промежуток его работы в компании изменится на интервал с 1 по 2 апреля. Через день интервал примет вид 1 – 3 апреля и так далее. Одним из путей решения подобной проблемы могло бы быть ежедневное обновление базы данных, изменяющее верхнюю границу интервала на корректное значение, но это нереальный вариант. Поэтому при выполнении запросов можно использовать подобную динамическую подстановку20. Для этого можно хранить динамическую константу СЕЙЧАС, обозначающую зависимость факта от текущего времени. В приведенном примере это бы означало, что человек работает в компании с 1 апреля по СЕЙЧАС. В качестве представления СЕЙЧАС можно использовать одно из значений домена TIMESTAMP или пустое значение NULL. При выборе значения для представления СЕЙЧАС необходимо гарантировать, чтобы это значение не использовалось с каким-либо иным смыслом. Фактически, требуется сделать выбор из значения NULL и максимального или минимального значения типа TIMESTAMP. При использовании СЕЙЧАС в запросах необходимо принимать во внимание, что его следует заменять текущим временем на этапе выполнения. При работе над системой TimeDB [TIM07] исследовалась производительность системы для различных вариантов представлений. Было продемонстрировано, что представление СЕЙЧАС с помощью минимального 20

Если подстановка для CURRENT_TIMESTAMP, CURRENT_DATE и CURRENT_TIME выполняется для данных запроса, то здесь подстановка выполняется для информации, хранимой в базе данных. 95

значения типа TIMESTAMP всегда самое медленное. Представление в виде NULL было наиболее эффективным при большем проценте пересечений с текущим временем. Однако представление в виде NULL-значения всегда приводило к максимальному количеству чтений диска. На основе этого анализа был сделан выбор в пользу максимального значения типа TIMESTAMP. Использование некоторого специального значения СЕЙЧАС не является единственно возможным решением. Например, можно разделить все факты на два класса, в одном из которых хранятся факты, для которых интервал уже точно известен, а в другом – те, у которых верхняя граница еще не известна. Если хранить эти факты в разных таблицах, то не потребуется вводить специальное значение СЕЙЧАС, однако несколько усложнится выборка, а таблицы с поддержкой и транзакционного, и действительного времени придется разбивать на четыре подтаблицы. Выше речь шла о представлении значения СЕЙЧАС в системе, однако важна и его интерпретация. Например, тот факт, что сотрудник работает с 1 апреля по СЕЙЧАС, не подтверждает, но и не опровергает, что на следующей неделе он также будет работать. Но для другого сотрудника может быть известно, что он работает только до конца этой недели, и поэтому в отчетах за данную неделю о сотрудниках, которые будут работать на следующей неделе, второй сотрудник фигурировать не должен, а про первого сказать ничего нельзя. Поэтому корректная интерпретация значения СЕЙЧАС возможна лишь для прошлого. При работе с событиями будущего необходимо проявлять осторожность и точно понимать, что и каким образом должно быть получено в качестве результата задаваемого запроса.

5.5. Разрежение таблиц с темпоральной поддержкой Если говорить о таблицах с темпоральной поддержкой, то причиной снижения производительности может стать постоянно возрастающий объем хранимых данных. Это, в первую очередь, относится к таблицам с темпоральной поддержкой транзакционного времени, так как в таких таблицах данные физически не удаляются из системы, а лишь добавляются (в том числе и при модификации записей). С другой стороны, через определенный промежуток времени оказывается, что часть данных устарела, и поэтому их было бы желательно физически удалить из системы, так как они не только занимают место, но и снижают производительность при выборках. Но подобное физическое удаление подвергает риску общую целостность хранящихся данных. Поэтому фундаментальным требованием является возможность контролирования физического удаления данных, что приводит к операции, которая называется разрежением (vacuuming) таблиц с темпоральной поддержкой. Для обеспечения корректности выполнения разрежения необходимо иметь возможность указывать в запросе данные, которые должны 96

быть удалены, и те, которые должны быть оставлены. Очевидно, что все «активные» строки должны остаться в таблице при любом ее разрежении. В простейшем случае отбрасываются все те кортежи, которые были удалены21 до определенного момента времени – происходит срез истории. Но подобное разрежение является не совсем корректной операцией. Например, пусть мы хотим сделать выборку состояния на какой-нибудь момент времени A, предшествующий аргументу среза B (A < B), когда в таблице находились некоторые строки X и Y, первая из которых была удалена до момента времени B, а вторая – нет. Тогда в качестве результата запроса будет выдана строка Y, но не X. Многие запросы могут начать неправильно работать, и к ним, скорее всего, будут относиться все запросы, использующие агрегатные функции. Чтобы обезопасить себя от части подобных проблем, можно предложить специальный вариант среза, когда нижняя граница интервала транзакционного времени для всех строк становится равной моменту времени среза, если этот момент принадлежал исходному интервалу. Но и в этом случае искажается информация о времени истинного появления строки в системе. Поэтому разрежение темпоральных таблиц не является однозначным решением, и в каждом конкретном случае необходимо отдельно рассматривать все плюсы и минусы. Отметим, что с точки зрения работы с системой и формулировки запросов нет необходимости в разрежении, однако переполнение базы данных «устаревшими» сведениями может негативно сказываться на производительности. От негативных последствий проблемы зависимости поведения приложений при проведении разрежения можно частично избавиться, если вместо реального удаления данных выполнить их перенос на другой доступный носитель. Например, данные из одной базы переносятся в другую, расположенную на другом сервере, причем в исходной базе остается информация об этом переносе. В этом случае при необходимости обращения к истории запрос может быть перенаправлен или объединен с результатом выборки из другой базы данных. Проблема с «разрежением» таблиц относится к транзакционному времени, но она также рассматривается и с точки зрения действительного времени. Например, если речь идет о хранении некоторых промежуточных версий какого-либо документа, то может оказаться, что интерес представляет лишь окончательная версия за январь прошлого года, а все промежуточные версии можно удалить. В этом случае можно также воспользоваться разрежением, но выбор доступных методов гораздо шире, например, можно оставить каждый третий документ или не больше одного документа в месяц, а само разрежение применить к документам прошлого года.

21

В терминах транзакционного времени. 97

5.6. Проектирование темпоральных баз данных В настоящее время существуют проверенные методы и инструментарий, используемые при проектировании реляционных баз данных. При работе с темпоральными базами данных необходимо учитывать темпоральную специфику и использовать соответствующие средства. Рассмотрим простой вопрос: сколько в базе данных должно быть таблиц с темпоральной поддержкой? Если для действительного времени ответ на данный вопрос достаточно прост (количество таблиц определяется потребностью приложений), то при наличии транзакционного времени он становится нетривиальным, так как от ответа от него зависит объем накапливаемой истории. При этом не всегда требуется именно поддержка транзакционного времени, а вполне может подойти и простой журнал, реализованный вне базы данных. При проектировании таблиц с поддержкой действительного времени можно использовать обычные инструменты, дополняя таблицы интервалами (парой значений) времени, однако в этом случае количество связей между таблицами заметно увеличивается. Более того, невозможно корректно описать работу со специальным значением СЕЙЧАС. При проектировании темпоральной базы данных следует также помнить, что все «обычные» реляционные ключи таблиц будут неявно расширяться верхней границей интервала транзакционного и/или действительного времени. Ограничения целостности также должны формулироваться с учетом этих обстоятельств ([JT95]). Если темпоральная поддержка используется не для всех таблиц, то возникает вопрос, связанный с выборкой данных из нескольких таблиц на какой-либо момент прошлого: что делать с совместными выборками из таблицы с поддержкой транзакционного времени и из таблицы без подобной поддержки? Вполне возможно, что результат выборки будет неверен, так как информация из обычной таблицы могла быть уже удалена или изменена, а в соответствующей темпоральной таблице остались внешние связи. Таким образом, если разрешить подобные выборки, то могут возвращаться некорректные результаты. Если же такие выборки запретить, то становится непонятно, как работать с потенциально константными данными, например, названиями дней недели, которые могут храниться в таблице без темпоральной поддержки. Принудительное добавление темпоральной поддержки для всех таблиц также не является лучшим выходом, так как усложняет алгоритм работы СУБД и требует дополнительных ресурсов.

5.7. ACID-свойства темпоральных транзакций Основными свойствами традиционных транзакций, поддерживаемыми в реляционных СУБД, являются ACID (атомарность, целостность, изолированность и продолжительность). При создании темпоральной СУБД чрезвычайно важно перенести подобные свойства и на темпоральные транзакции. ACID-свойства темпоральных SQL-транзакций могут быть 98

сохранены за счет отображения каждой темпоральной транзакции в одиночную реляционную SQL транзакцию. Альтернативные реализации темпоральных транзакций, при которых proxy-уровень отображает темпоральную SQL-транзакцию в несколько обычных SQL-транзакций, могут привести к неразрешимым проблемам, если во время выполнения получится так, что одна из реляционных SQL-транзакций будет зафиксирована, а вторая – нет, что должно означать неудачу всей темпоральной SQL-транзакции, а не отдельной ее части. Выполнить же откат транзакции, зафиксированной в базе данных, может оказаться просто невозможно, так как изменения уже могут быть использованы параллельно работающими транзакциями. Поэтому для поддержки параллельно работающих темпоральных транзакций необходимо реализовывать их в виде одиночных SQL-транзакций, иначе не удастся обеспечить поддержку ACID-свойств22. Кроме этого, недостаточно требовать только то, чтобы каждая темпоральная SQL транзакция отображалась в одну SQL-транзакцию. Для каждой транзакции необходимо обеспечить, чтобы в ее пределах транзакционное время было константно, но тогда встает вопрос, как его выбирать, ведь условия на специальное значение СЕЙЧАС должны проверяться с тем же значением константы. Здесь возможны два основных варианта: транзакционное время выбирается в самом начале или в самом конце выполнения транзакции. Первый вариант является некорректным, так как параллельная транзакция может внести изменения в таблицы, которые еще только понадобятся данной транзакции. Поэтому наиболее удачным выбором является момент времени непосредственно перед фиксацией транзакции, после того, как получены блокировки на все затрагиваемые объекты. Но и здесь возможны проблемы, если транзакция получит одно значение транзакционного времени, а будет зафиксирована чуть позже, так что между этими двумя моментами будет благополучно выполнена некорректная выборка. Подобная проблема может возникнуть и при параллельном выполнении двух различных транзакций. Один из способов, который сможет гарантировать корректную поддержку ACID-свойств темпоральных транзакций, состоит в реализации дополнительного механизма блокировок на proxy-уровне. Отметим, что восстановление базы данных, которое является важной частью работы СУБД, является прозрачным для конечного пользователя. При использовании многоуровневой архитектуры для конечного пользователя промежуточный слой ничем не отличается от СУБД, поэтому при проектировании прослойки можно полностью положиться на механизмы восстановления, реализованные в СУБД. Также нет причин, по которым они стали бы работать быстрее или медленнее. 22

Если, конечно, не реализовывать на proxy-уровне собственный механизм управления транзакциями над механизмом управления транзакциями базовой СУБД. 99

5.8. Эффективность при работе с темпоральной СУБД Одним из наиболее важных вопросов при использовании баз данных является эффективность работы приложений с соответствующей СУБД. Для повышения скорости обработки запросов в реляционных СУБД традиционно применяются индексы для выборки данных из таблиц, а также статистики и различные эвристики при выборе алгоритма соединения данных из нескольких таблиц ([GJS+05]). При разработке темпоральных СУБД значительное внимание уделялось именно вопросам производительности, так как в общем случае небольшая доля «активных» данных из постоянно растущего объема информации в базе данных приводила к резкому спаду производительности при интенсивном использовании и/или недостаточном внимании при разработке приложения. Наиболее очевидным, а также доступным способом оптимизации темпоральных приложений является использование индексов. Например, при добавлении дополнительных специальных столбцов для интервалов транзакционного времени необходимо включить верхний предел во все уникальные индексы. С другой стороны, необходимость постоянно разделять данные на «активные» и «устаревшие» требует их разделения на ранней стадии обработки, что также может быть обеспечено с помощью индексов. Аналогичная ситуация возникает при соединении темпоральных таблиц, так как оно часто проводится именно по специальным темпоральным столбцам. Однако встает вопрос: должны ли темпоральные столбцы располагаться до или после остальных столбцов (обычного реляционного) индекса? Если они будут идти после всех обычных столбцов, то система получится почти «реляционной», так как большинство операций вначале будет выполняться именно на основе реляционных условий, а лишь затем будет применяться ограничение по времени, а значит, все проблемы с огромным объемом информации ложатся на традиционное реляционное ядро СУБД. Если же темпоральные столбцы будут располагаться перед обычными, то объем обрабатываемых данных будет напрямую зависеть лишь от наличия ограничений на темпоральные столбцы; например, при попытке получить историю отдельного кортежа при отсутствии темпоральых ограничений системе придется просмотреть историю всех кортежей (точнее, полностью весь индекс). Кроме того, подобный индекс будет довольно часто перестраиваться при изменениях данных темпоральных столбцов. С другой стороны, единственным изменением кортежа в таблице с темпоральной поддержкой транзакционного времени является установка вместо СЕЙЧАС точной верхней границы интервала (в момент удаления или изменения кортежа). Описанные выше проблемы касались выборок из одной темпоральной таблицы. Наибольший же интерес представляют выборки из нескольких таблиц и соответствующее соединение результатов. До сих пор разрабатываются различные алгоритмы и предлагаются эвристики для 100

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

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

6.1. Темпоральные базы XML-данных В начале этого века формат XML, по сути, стал стандартом представления данных для обмена в сети. Разработчики реляционных СУБД начали включать поддержку XML в свои продукты. Одновременно с этим многие исследователи темпоральных баз данных обратили свое внимание на возможность работы с темпоральными базами XML-данных. Первоначально большие надежды возлагались на создание темпоральной XML-СУБД, так как стандарт языка темпоральных запросов еще не был окончательно принят, а для его реализации потребовалось бы создание новых алгоритмов, оптимизаторов и т.п.; поэтому внесение темпоральной поддержки в ядро 101

XML-СУБД было вполне вероятным. Однако многие производители реляционных СУБД минимальными усилиями добавили в свои продукты поддержку баз XML-данных, а не стали создавать новые системы. Имеется несколько работ, в которых предлагается темпоральное расширение языка XQuery [GS03], а также описываются темпоральные системы, предназначенные для хранения XML документов [GS03+]. В отличие от реляционной модели, в которой обычно используется плоское представление данных, в XML изначально применяется древовидное представление, поэтому появляется больше вариантов темпоральной поддержки. Например, метки времени могут являться наследуемыми атрибутами, что позволяет несколько упростить формулировку многих запросов и применить дополнительные способы оптимизации. С другой стороны, плоская структура является более «предсказуемой» при работе и позволяет гораздо проще можно получить многие оценки, необходимые оптимизатору. Темпоральные базы XML-данных используются в тех случаях, когда исходные данные являются плохо структурированными или уже представлены в формате XML.

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

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

102

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

6.4. Механизм снимков состояний Одним из частных случаев темпоральных баз данных является система с поддержкой снимков состояний. Механизм снимков состояний является самым простым способом реализации темпоральной поддержки, но приемлемым лишь в ограниченном количестве случаев. Снимок реляционной таблицы является независимой копией текущего состояния этой таблицы во время создания снимка. Соответственно, снимки получаются из базовых таблиц, но они не могут уже изменяться после создания, даже если меняются базовые таблицы. Общий механизм снимков состояний может быть применен тремя различными способами. Во-первых, возможно ручное создание снимка состояния по специальной команде СУБД, например, generate-snapshot, которая создает снимок. Этот подход можно назвать созданием «ручного альбома». Второй подход состоит в автоматическом создании снимков через определенный пользователем промежуток времени; например, можно создавать снимок в конце каждого месяца и хранить его в течение года. Можно считать, что такой подход приводит к появлению «автоматического альбома». При третьем подходе снимки создаются последовательно по мере изменения базовой таблицы, то есть новый снимок создается каждый раз, когда обновляется состояние. Это уже можно назвать «съемкой фильма». Подобный механизм может применяться для обычных таблиц, но нет никаких оснований, чтобы не применять его для событий, связанных с историей. Последовательные снимки таблицы (третий подход) приводят почти к обычной темпоральной таблице. При применении каждого из первых двух подходов получается темпоральная таблица специального вида.

23

Здесь мы используем термин «пространственно-временные», а не «пространственно-темпоральные» базы данных, так как он подходит больше, а путаницы с ударением не возникает. 103

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

7. Предложения СУБД

от

производителей

коммерческих

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

7.1. TimeDB Прототип темпоральной СУБД TimeDB был создан в 1997 г. Андреасом Стейнером в ходе работы по подготовке его диссертации [Ste98]. В прототипе поддерживалось как действительное, так и транзакционное время, но он был привязан к конкретной реляционной СУБД, так как в нем использовался интерфейс уровня вызовов компании Oracle. Позже была выпущена версия TimeDB 2.0, реализованная на языке Java. Для работы с реляционной СУБД использовался интерфейс JDBC, поэтому не было привязки к конкретному 104

производителю. Версию TimeDB 2.0 Beta 4 можно свободно скачать с сайта компании TimeConsult в исследовательских целях [TIM07]. Неизвестны дальнейшие пути развития проекта или какие-либо изменения в системе, произошедшие после 1999 года.

7.2. Informix TimeSeries Datablade Модуль TimeSeries компании Informix предназначен для обработки и анализа динамики процессов на основе временных рядов данных. Он содержит определение новых типов данных – временного ряда и календаря, а также предоставляет более сорока функций для обработки данных, содержащих временные метки. Данный модуль предоставляет большие возможности по анализу динамики отдельного процесса, а также эффективному хранению данных и доступа к ним. Если ряд является регулярным, то доступ константен для любого момента времени. Здесь присутствует оптимизация вполне конкретного пути доступа, поэтому нельзя назвать TimeSeries Datablade полноценным темпоральным решением для действительного времени.

7.3. Immortal DB (прототип от Microsoft) Целью проекта Immortal DB, реализованного исследовательским подразделением Microsoft, было предоставление поддержки транзакционного времени, встроенной в SQL сервер, а не основанной на каком-либо proxyуровне ([LBM+05]). Была предпринята попытка продемонстрировать, что в СУБД, кроме поддержки снимков, может быть реализована полноценная поддержка транзакционного времени, причем с хорошей производительностью. При реализации поддержки был расширен стандартный механизм сномков состояния, позволяющий получить некоторый снимок базы данных на момент времени прошлого. Одна из проблем, стоявших перед разработчиками, состояла в обеспечении обновлений и модификации данных при минимальных дополнительных затратах, поэтому была введена поддержка разбиения файловых страниц базы данных при переполнении как по ключу, так и по временному атрибуту. Механизмы контроля параллельного доступа и восстановления были полностью интегрированы с соответствующими функциями MS SQL Server.

7.4. Технология Oracle Flashback – шаг к темпоральной СУБД В Oracle9i появился механизм Flashback Query [Ora07a] – мощный, простой и полностью безопасный способ восстановления системы от ошибок пользователя. Он также позволяет пользователям без внесения каких-нибудь структурных изменений в базу данных просмотреть состояние базы данных на какой-либо момент в прошлом. Данная технология позволяет исправлять пользовательские ошибки. Операции Flashback Query могут выполняться без участия администратора, и это позволяет разработчикам добавлять в свои приложения функции восстановления данных. Для использования Flashback Query требуется включение автоматического управления восстановлением 105

(Automatic Undo Management) вместо использования сегментов отката (Rollback Segments). При этом в Flashback Query используются именно данные восстановления, поэтому его использование не сказывается на производительности. В Oralce9i механизм Flashback Query позволял получить доступ только к некоторому статическому снимку данных. В Oracle10g к данной технологии добавились еще несколько средств: Flashback Versions Query позволяет получить вместо статической картинки «фильм» изменений, Flashback Transaction Query дает возможность увидеть изменения, внесенные заданной транзакцией, а средства восстановления Flashback Database, Flashback Query и Flashback Drop позволяют вернуться к предыдущему состоянию за константное время, не зависящее от объема базы данных. Если подвести некоторый итог, то можно сказать, что СУБД Oracle стала уже почти темпоральной СУБД (с поддержкой транзакционного времени). Однако создание сколько-нибудь сложного запроса с использованием технологии Flashback опять полностью зависит от разработчика, так как никакой дополнительной поддержки множественных темпоральных операций не предусмотрено. Кроме того, даже для разрешенных темпоральных запросов существуют довольно жесткие ограничения.

7.5. Решение Oracle Workspace Manager – многоверсионность данных и поддержка снимков состояний Кроме рассмотренной ранее технологии Oracle Flashback в Oracle 10g можно использовать механизм Oracle Workspace Manager – это одна из возможностей СУБД, позволяющая управлять текущими, предполагаемыми и историческими значениями данных в одной и той же базе данных [Ora07b]. Oracle Workspace Manager использует рабочие пространства в качестве виртуального окружения для изоляции совокупности изменений данных, хранения истории изменений данных и создания множественных сценариев развития для анализа возможного будущего. Создаваемые рабочие пространства могут наследоваться от других рабочих пространств или стандартного «актуального» рабочего пространства LIVE (по умолчанию). При этом фиксируется текущее состояние рабочего пространства-предка. В рамках конкретного рабочего пространства также можно использовать точки сохранения, которые позволяют откатывать изменения к определенному моменту прошлого. Также предусмотрены операции по слиянию рабочего пространства-потомка с рабочим пространством-предком. Отдельный интерес представляет опция полного отслеживания всех изменений данных, включая операции добавления, удаления и обновления. Фактически, это поддержка транзакционного времени. С точки зрения работы с темпоральным данными стоит отметить возможность зафиксировать запросы на указанный момент времени. С технической точки зрения рабочие пространства представляют собой набор представлений базы данных с обработчиками триггеров INSTEAD OF. Когда 106

пользователь желает добавить для таблицы поддержку версионности, менеджер рабочих областей переименовывает таблицу в _LT, добавляя к ней четыре служебных столбца, после чего создает представление с названием исходной таблицы , для которого обработчики триггеров INSTEAD OF производят необходимые действия по изменению данных в исходных таблицах. Если немного упрощать, то данное решение является решением промежуточного слоя, только реализованного непосредственно внутри конкретной СУБД. СУБД Oracle еще не стала полностью темпоральной СУБД, несмотря на наличие средства Oracle Workspace Manager, в котором была реализована часть идей SQL/Temporal. Однако прослеживаемая тенденция позволяет утверждать, что работы над созданием полноценной реализации темпоральной СУБД со стороны производителей коммерческих систем ведутся. Более того, для конкретных классов задач создаются отдельные темпоральные расширения, которые проходят «боевую» проверку на реальных задачах.

8. Актуальные вопросы исследований

и

задачи,

перспективы

При описании темпоральных систем уже подчеркивалось наличие отдельных проблем, которые должны быть решены прежде, чем будет создана полноценная темпоральная СУБД. С другой стороны, опыт технологии Oracle Flashback показывает, что для конкретной задачи можно реализовать специализированную темпоральную поддержку. Кроме того, существует множество проблем и задач, которые могут быть решены в рамках исследований в области темпоральных и пространственно-временных баз данных [RHE+04]. В этом разделе перечисляются некоторые из подобных задач.

8.1. Эффективные представления

пользовательские

интерфейсы

и

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

8.2. Извлечение данных и знаний из пространственновременных систем Важными областями исследований являются извлечение информации и обнаружение знаний. Большинство работ может быть разделено на три категории: 





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

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

8.3. Новый уровень мобильности Относительно недавно появились беспроводные устройства для определения местонахождения и сети сенсоров. Это сделало возможным появление систем, поддерживающих мобильных пользователей способами, которые были невозможны ранее. В таких системах требуется поддержка пространственновременных баз данных в условиях интенсивных потоков данных от беспроводных устройств.

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

8.5. Нетрадиционные методы доступа

107

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

пространства используются графы, а не евклидово представление пространства. Вместо евклидовых расстояний могут использоваться расстояния на дороге. Методы доступа к подобным данным должны соответствовать специфике проблемы. Исследования методов доступа к пространственно-временным данным, главным образом, фокусируются на двух аспектах: (1) хранение и поиск исторической информации и (2) предсказание будущего. Для решения первой задачи было предложено несколько индексных структур, минимизирующих объем хранимых данных и стоимость выполнения запроса. Подобные индексы обычно основываются на многоверсионных или трехмерных вариациях R-деревьев. Методы для предсказания будущего основаны на том предположении, что в дополнение к текущей позиции объектов известны и скорости их движения. Целью является нахождение объектов, которые будут удовлетворять пространственным условиям в некоторый момент (или интервал времени) будущего на основе заданных текущих скоростей движения (например, «на основе текущей информации найти все машины, которые будут в центре города через 10 минут»). Индексы, практически пригодные для предсказания будущего, основываются на TPR-деревьях и их вариациях (также являющих развитием идей R-деревьев). Несмотря на огромное количество методов, которые явно фокусируются на выборку исторических данных или предсказание будущего, сейчас не существует ни одной индексной структуры, которая могла бы эффективно содействовать достижению обеих целей. Даже если бы существовала универсальная структура (например, многоверсионное TPR-дерево, сохраняющее всю предыдущую историю каждого объекта), она была бы неприменимой для некоторых приложений с интенсивным обновлением. Например, обновление (удаление или повторная вставка) TPR-дерева может привести к доступу более чем к 100 вершинам, и можно просто не успеть выполнить эту операцию до момента следующего обновления этого же объекта. Даже при небольшом числе движущихся объектов и небольшой скорости обновлений TPR-дерево (или любой другой индекс) не может «следить» за быстрыми изменениями данных. Поэтому для приложений с интенсивным обновлением кажутся более подходящими структуры данных в основной памяти, и в этой области необходимы дальнейшие исследования.

8.6. Новые типы пространственно-временных запросов Существует множество областей, где могут быть эффективно использованы пространственно-временные базы данных, но для решения задач оказываются недостаточными возможности формулировки запросов языка SQL. К запросам нового типа относятся непрерывные запросы, где результат сильно зависит от темпорального контекста. Примером непрерывного запроса может служить следующий: «на основе текущего положения и скорости автомобиля найти две ближайшие АЗС в течение следующих пяти минут?» Результат в форме , означает, что АЗС A и B будут ближайшими в 109

интервале времени [0,1), а АЗС B и C – в интервале [1,5). Заметим, что соответствующий моментальный запрос («какие две АЗС являются сейчас ближайшими?») в высоко динамичном окружении обычно будет бессмысленным: если точка запроса или объект базы данных двигается, то результат может сразу стать недействительным. В любом пространственном запросе имеется непрерывная составляющая, условие завершения которой зависит от потребностей пользователя или приложения. Рассмотрим, например, оконный запрос, где окно (и, возможно, объекты базы данных) двигается и/или изменяется с течением времени. Условием завершения может быть время (следующие пять минут), условие на результат (например, пока в окне запроса не останется только один объект, или пока результат не изменится три раза), условие на окно запроса (пока окно запроса не достигнет определенной точки в пространстве) и т.д. Основным отличием от непрерывных запросов к традиционным базам данных является то, что в случае пространственно-временных баз данных для фиксации динамического поведения объекта не обязательно требуются обновления базы данных; поведение может сохраняться как функция от времени с использованием подходящих индексов. Кроме того, даже если объекты остаются статическими, результаты могут изменяться из-за динамической природы самого запроса (например, движущееся окно запроса), который также может быть представлен в виде функции от времени. Таким образом, пространственно-временной непрерывный запрос может быть вычислен немедленно (в текущий момент времени) с использованием параметризованной информации о динамическом поведении запроса или объектов базы данных, и будет выдано несколько результатов, каждый из которых относится к соответствующему интервалу времени в будущем.

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

8.8. Неопределенности при обработке «неточных» данных Неопределенность присуща большинству пространственно-временных приложений из-за ошибок в измерениях/оцифровке и отсутствия или неполноты информации. Допустим, например, что пользователь с карманным компьютером хочет узнать расстояние по шоссе до ближайшего ресторана. Хотя пользователь может находиться на некотором участке дороги, система может не суметь определить это из-за неточности GPS-приемника. В подобных ситуацих может задаваться допуск dT, такой что любая точка, удаленная от дороги на расстояние, не большее dT, считается находящейся на дороге. В качестве альтернативы можно привязать точку к ближайшей дороге, предполагая наличие неполноту информации (например, наличие незарегистрированного проезда улицу), или считать дорогу недоступной в зависимости от особенностей приложения. Похожие проблемы существуют для траекторий объектов, так как движение непрерывно, а измерения дискретны. При разработке приложений необходимо также учитывать возможность соединения нескольких таблиц, в каждой из которых данные могут быть неточны. В этом случае требуется разработка специальных индексов и оптимизация хранения информации, чтобы подобные запросы выполнялись эффективно, причем в результат может быть включен и показатель неопределенности.

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

но остается очень много неисследованных исследовательских и прикладных областях.

проблем

в

смежных

Литература [AJS95]

[BBJ+97]

[BBJ98]

[Böh95] [BZ82] [CDI+97]

[DDL02] [GJS+05] [GS03]

[GS03+]

[Jcc07] 112

Arie Segev, Christian S. Jensen, and Richard T. Snodgrass. Report on The 1995 International Workshop on Temporal Databases. ACM SIGMOD Record 24(4), December 1995, http://acm.org/sigmod/record/issues/9512/temporal.ps J. Bair, M. H. Böhlen, C. S. Jensen, and R. T. Snodgrass. Notions of Upward Compatibility of Temporal Query Languages. Wirtschaftsinformatik, 39(1):25–34, February 1997, http://www.cs.aau.dk/~csj/Thesis/pdf/chapter24.pdf M. H. Böhlen, R. Busato, and C. S. Jensen. Point-Versus IntervalBased Temporal DataModels. In Proceedings of the Fourteenth International Conference on Data Engineering, pp. 192–200, Orlando, Florida, February 1998, http://www.cs.aau.dk/~csj/Thesis/pdf/chapter7.pdf Michael H. Böhlen. Temporal Database System Implementations. ACM SIGMOD Record 24(4), December 1995, http://www.sigmod.org/record/issues/9512/tdbms.ps J. Ben-Zvi, “The Time Relational Model,” PhD thesis, Computer Science Dept., UCLA, 1982 J. Clifford, C. E. Dyreson, T. Isakowitz, C. .S. Jensen, and R. T. Snodgrass. On the Semantics of ‘Now’ in Databases. ACM Transactions on Database Systems, 22(2), June 1997, http://www.cs.aau.dk/~csj/Thesis/pdf/chapter4.pdf C.J. Date, Hugh Darwen, Nikos Lorentzos. Temporal Data & the Relational Model. Morgan Kaufmann; 1st edition, November 19, 2002 Dengfeng Gao, S. Jensen, T. Snodgrass, D. Soo. Join operations in temporal databases. The VLDB Journal, Volume 14 Issue 1, 2005, http://www.cs.aau.dk/~csj/Papers/Files/2004_gaoVLDBj.pdf Dengfeng Gao and Richard T. Snodgrass. Syntax, Semantics, and Query Evaluation of the τXQuery Temporal XML Query Language, TimeCenter TR-72, March 2003, http://oldwww.cs.aau.dk/research/DP/tdb/TimeCenter/TimeCenterPub lications/TR-72.pdf Dengfeng Gao and Richard T. Snodgrass. Temporal Slicing in the Evaluation of XMLQueries. Proceedings of the 29th VLDB Conference, Berlin, Germany, 2003, http://www.vldb.org/conf/2003/papers/S19P03.pdf JCC's SQL Standards Page. http://jcc.com/SQL.htm JCC Consulting, 2007

[JT95]

[LBM+05]

[Ora07a] [Ora07b] [RHE+04]

[SAAB95]

[SBJ96a]

[SBJ96b]

[Sno96]

[Sno97]

Jan Chomicki and David Toman. Implementing Temporal Integrity Constraints Using an Active DBMS. IEEE Transactions on Knowledge and Data Engineering 7(4), August 1995, http://www.cs.uwaterloo.ca/~david/papers-ride94.ps Lomet, D., Barga, R., Mokbel, M., Shegalov, G., Wang, R., and Zhu, Y. Immortal DB: Transaction Time Support for Sql Server. SIGMOD Conference, Baltimore, MD, June 2005, http://www-users.cs.umn.edu/~mokbel/ImmortalDBDemo.pdf Технология Oracle Flashback, http://www.oracle.com/technology/deploy/availability/htdocs/Flashba ck_Overview.htm, 2007. Oracle Workspace Manager, http://www.oracle.com/technology/products/database/workspace_man ager/, 2007. Roddick, J. F., Hoel, E., Egenhofer, M. J., Papadias, D., and Salzberg, B. Spatial, temporal and spatio-temporal databases - hot issues and directions for phd research. SIGMOD Rec. 33(2), June 2004, http://acm.org/sigmod/record/issues/0406/RR1.SSTDpaper.pdf Richard T. Snodgrass, editor, Ilsoo Ahn, Gad Ariav, Don Batory, James Clifford, Curtis E. Dyreson, Ramez Elmasri, Fabio Grandi, Christian S. Jensen, Wolfgang Kaefer, Nick Kline, Krishna Kulkarni, T. Y. Cliff Leung, Nikos Lorentzos, John F. Roddick, Arie Segev, Michael D. Soo and Suryanarayana M. Sripada, The TSQL2 Temporal Query Language, Kluwer Academic Publishers, 1995. Спецификация TSQL2 доступна по адресу ftp://ftp.cs.arizona.edu/tsql/tsql2/bookspec.pdf, а комментарии – на ftp://ftp.cs.arizona.edu/tsql/tsql2/eval.pdf Snodgrass, R. T., M. H. Böhlen, C. S. Jensen and A. Steiner. Adding Valid Time to SQL/Temporal. ANSI X3H2-96-501r2, ISO/IEC JTC 1/SC 21/WG 3 DBL-MAD-146r2, November, 1996, http://www.cs.aau.dk/~csj/Thesis/pdf/chapter26.pdf Snodgrass, R. T., M. H. Böhlen, C. S. Jensen and A. Steiner. Adding Transaction Time to SQL/Temporal, ANSI X3H2-96-502r2, ISO/IEC JTC 1/SC 21/WG 3 DBL-MAD-147r2, November, 1996, http://www.cs.aau.dk/~csj/Thesis/pdf/chapter27.pdf Snodgrass, R.T. Addendum to Valid- and Transaction-time Proposals. ANSI X3H2-96-582, ISO/IEC JTC1/SC21/WG3 DBL MAD-203, November 1996, ftp://ftp.cs.arizona.edu/tsql/tsql2/sql3/ansi-96582.pdf Snodgrass, R.T. A Second Addendum to Valid- and Transaction-time Proposals. ANSI X3H2-97-010, ISO/IEC JTC1/SC21/WG3 DBL MAD-220, January 1997, http://www.informatik.uni-trier.de/~ley/db/systems/sql3.html 113

[Sno99] [Ste98]

[Tim07] [TJS98]

[Tom96]

[Tom98]

[TS01]

114

Richard T. Snodgrass. Developing Time-Oriented Database Applications in SQL. Morgan Kaufmann Publishers, 1999. Andreas Steiner. A Generalisation Approach to Temporal Data Models and their Implementations. Doctoral Thesis, ETH No.12434, Department of Computer Science, ETH Zurich, Switzerland, 1998, http://www.timeconsult.com/Publications/diss.pdf Официальный сайт проекта TimeDB, http://www.timeconsult.com/Software/Software.html K. Torp, C. S. Jensen, and R. T. Snodgrass. Stratum Approaches to Temporal DBMS Implementation. In Proceedings of the 1998 International Database Engineering and Applications Symposium, Cardiff, Wales, UK, July 1998, http://www.cs.aau.dk/~csj/Thesis/pdf/chapter39.pdf David Toman. Point vs. Interval-based Query Languages for Temporal Databases. Proceedings of the fifteenth ACM SIGACTSIGMOD-SIGART symposium on Principles of database systems, Montreal, Quebec, Canada, 1996, http://www.cs.uwaterloo.ca/~david/papers-pods96.ps D. Toman. Point-Based Temporal Extensions of SQL and Their Efficient Implementation. Temporal Databases: Research and Practice, Springer; 1st edition, July 1, 1998, http://citeseer.ist.psu.edu/cache/papers/cs/3096/http:zSzzSzsolo.uwate rloo.cazSz~davidzSzpapers-dagstuhl97.pdf/point-based-temporalextensions.pdf Paolo Terenziani, Richard T. Snodgrass. Reconciling Point-based and Interval-based Semantics in Temporal Relational Databases: A Proper Treatment of the Telic/Atelic Distinction, IEEE Transactions on Knowledge and Data Engineering, 16(5), May 2004, http://www.cs.arizona.edu/projects/stagg/papers/TR-60.pdf

Объектно-реляционные базы данных: прошедший этап или недооцененные возможности? С.Д. Кузнецов [email protected]

1. Введение Эпоха объектно-реляционных баз данных началась десять лет назад, когда в декабре 1996 года компания Informix выпустила объектно-реляционную систему управления базами данных (ОРСУБД) Informix Universal Server. Вслед за ней в 1997 г. на рынке появились ОРСУБД компаний Oracle (Oracle8) и IBM (DB2 Universal Database). В течение примерно трех лет новая технология интенсивно обсуждалась. Многим (включая меня) в то время казалось, что ОРСУБД в корне изменят способы проектирования и разработки приложений баз данных. Однако постепенно шум вокруг ОРСУБД затих. До конца 1990-х гг. Informix, Oracle и IBM совершенствовали свои ОРСУБД. В 1999 г. появился стандарт SQL:1999 [1], в котором были зафиксированы объектные расширения языка SQL. И, наконец, после выхода в 2003 г. стандарта SQL:2003 [2], уточнившего и дополнившего SQL:1999, в сообществе баз данных окончательно перестали обсуждать объектно-реляционную технологию баз данных. Что это означает? Оказалось ли дитя мертворожденным? Или же наш мир еще не готов к приходу нового мессии? Я не знаю, многих ли в мире сейчас это волнует, но мне кажется, что тема заслуживает обсуждения. Слишком много материальных и интеллектуальных ресурсов затратило человечество на разработку ОРСУБД, чтобы можно было позволить себе о них забыть. Слишком много полезных возможностей кроется в объектно-реляционном подходе, чтобы проектировщики и разработчики приложений баз данных могли с чистой совестью им пренебрегать. В этой статье я хочу, прежде всего, обсудить общее понятие объектнореляционных баз данных. Затем я коротко проанализирую основные черты и различия первых версий ОРСУБД компаний Informix, Oracle и IBM. Далее мы обсудим (снова очень кратко) предпосылки появления ОРСУБД. В следующем разделе части статьи будут рассмотрены наиболее важные аспекты языка SQL, имеющие отношение к организации объектно115

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

2. Понятие объектно-реляционных баз данных Термин объектно-реляционные базы данных стал известен широким массам разработчиков и пользователей систем баз данных после выпуска компанией Informix в конце 1996 г. своего нового продукта Informix Universal Server (IUS). Компания Informix смогла быстро разработать IUS благодаря приобретению компании Illustra и переходу на работу в Informix ее основателя Майкла Стоунбрейкера. По сути дела, IUS был получен в результате «скрещивания» основного серверного продукта Informix Dynamic Server и СУБД Illustra. В свою очередь, компания Illustra была основана, в основном, с целью коммерциализации известной СУБД Postgres, разработанной под руководством Майкла Стоунбрейкера в Калифорнийском университете в г. Беркли. (На основе Postgres позднее была создана СУБД PostrgreSQL, являющаяся в настоящее время одной из наиболее популярных СУБД категории Open Source.) Как известно, проект Postgres во многом представлял собой продолжение с использованием ряда новых идей (развитая система правил, поддержка темпоральных данных и т.д.) раннего проекта Майкла Стоубрейкера Ingres. Уже в Ingres можно было заметить некоторые черты, которые в наше время многими принято относить к числу объектных (в частности, зачаточные возможности определения пользователями новых типов данных). Однако Стоунбрейкер не называл ни Ingres, ни Postgres объектно-реляционными системами. По отношению к Postgres он использовал эпитет «СУБД следующего поколения». Стоунбрейкер начал называть ОРСУБД только систему Illustra, которая, по сути, отличалась от Postgres только поддержкой языка SQL. Тем самым, исторически IUS стало возможно именовать объектнореляционной СУБД именно по той причине, что эта система основывалась на Illustra, которая уже называлась объектно-реляционной. Однако значит ли это, что IUS можно считать некоторой эталонной моделью ОРСУБД, а Майкла Стоунбрейкера – отцом этого термина и направления в целом? С моей точки 116

зрения, это было бы неверно. Во-первых, как мы покажем в разд. 4, у объектно-реляционного подхода имеются и другие предпосылки. Во-вторых, в разд. 3 мы кратко продемонстрируем, что в IUS имелись некоторые особенности (большей частью, весьма полезные), которые делают эту систему не слишком пригодной в качестве эталонной модели. Так что же такое ОРСУБД? Что такое объектно-реляционная база данных? Если не зафиксировать какое-либо конкретное понимание этих терминов, то, очевидно, рассуждения на их тему становятся бессмысленными. Заметим, что банальное житейское толкование термина ОРСУБД как традиционной реляционной СУБД, расширенной основными объектными возможностями, является опасно упрощенным и искажающим действительность. Во-первых, имеющиеся сегодня на рынке ОРСУБД не являются «традиционными реляционными», поскольку в них не поддерживается реляционная модель данных. Они основаны на другой модели данных, представленной в стандарте языка SQL. Во-вторых, объектный мир определен в целом настолько расплывчато и нечетко, что невозможно однозначно говорить об основных объектных возможностях. Поэтому в данной статье я не буду пытаться приводить сжатые дефиниции ОРСУБД. С моей точки зрения, сегодня под ОРСУБД следует понимать системы, которые следуют духу Манифеста систем баз данных третьего поколения [3] и букве стандартов SQL:1999 и SQL:2003 [1-2]. В качестве примеров реализаций ОРСУБД можно использовать Oracle (начиная с Oracle 9i) и IBM DB2 (начиная с версии 7).

3. Первые реализации В этом разделе я кратко опишу основные особенности первых СУБД компаний Informix, Oracle и IBM, которые на рынке назывались объектнореляционными. Целью раздела является воссоздание исторического контекста, а также выделение базовых свойств, которые впоследствии были зафиксированы в стандарте SQL и являются характеристиками современных ОРСУБД. В описании я буду придерживаться хронологического порядка.

3.1. Informix Universal Server Итак, первой системой, выпущенной на рынок в качестве РСУБД крупной софтверной компанией, стал Informix Universal Server (IUS). Это произошло в конце декабря 1996 г. – начале января 1997 г. и является основным поводом для отмечания 10-летнего юбилея подхода. IUS было посвящено много публикаций, в том числе, очень содержательные статьи [4-5]. Однако здесь я не буду следовать порядку изложения, принятому в этих статьях, а напишу так, как мне представляется правильным сегодня.

3.1.1. Интеллектуальные большие объекты Интеллектуальные большие объекты (smart large objects), поддерживаемые в IUS, позволяли снять неприятные реализационные ограничения, характерные для трактовки больших объектов (BLOB или CLOB) реляционными СУБД. Интеллектуальные большие объекты могли подвергаться журнализации и откату, что важно для сохранения целостности и доступности данных. Операторы SQL имели дело не с самими большими объектами, а с их описателями. Эти описатели помещались в столбцы таблиц, передавались подпрограммам, написанным с использованием встроенного SQL и т.д. Прикладная программа, получив описатель интеллектуального большого объекта, могла работать с ним примерно так же, как и с файлом операционной системы.

3.1.2. Определение новых базовых типов данных СУБД IUS позволяла вводить новые базовые типы данных. При этом можно использовать встроенные в IUS методы доступа и хранения, а также определять новые.

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

3.1.2.2. Типы со скрытой структурой В соответствии с идеологией IUS, потребность во введении нового базового типа данных может возникать и по причине принципиального отсутствия нужного типа. Для этого поддерживался механизм определения типов со скрытой структурой (opague type). Типы со скрытой структурой являлись абстрактными в строгом смысле этого слова. СУБД IUS была лишена какойлибо информации о внутреннем устройстве этих типов и могла манипулировать соответствующими значениями только посредством предоставленных разработчиком функций. Чтобы определить новый тип данных со скрытой структурой, требовалось выполнить следующую последовательность действий:  описать на языке C (или другом внешнем языке) структуру определяемых объектов;  написать на языке C (или другом внешнем языке) вспомогательные функции, вызываемые сервером СУБД;

117

118

 зарегистрировать определяемый тип в базе данных посредством оператора CREATE OPAQUE TYPE;

CREATE ROW TYPE ( ( , . . . );

 зарегистрировать вспомогательные функции посредством операторов CREATE FUNCTION и CREATE CAST;

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

 предоставить права доступа к определяемому типу вспомогательным функциям посредством оператора GRANT;

и

его

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

3.1.2.3. Специальные методы хранения, поиска и индексации В IUS можно было также определять новые базовые типы данных одновременно с введением специальных алгоритмов хранения, доступа и индексирования, которые отличались от стандартных алгоритмов, реализованных в сервере. Для введения нового базового типа данных с нестандартными методами доступа нужно было определить набор серверных функций, реализующий для нового типа алгоритмы доступа, просмотра, выделения памяти и т.д. Эти функции должны были быть написаны на языке C и скомпилированы в объектный формат. Далее нужно было описать новый базовый тип данных и указать функции, реализующие для этого типа алгоритмы извлечения и записи на диск значений данного типа. Заметим, что какая-либо поддержка типов данных со скрытой структурой в других реализациях ОРСУБД или в стандарте SQL отсутствует. Это первый пример уникальных возможностей IUS, связанных, по моему мнению, с архитектурными особенностями линии СУБД Ingres-Postgres-Illustra.

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

3.1.3.1. Тип данных со структурой записи В SQL IUS тип данных со структурой записи определялся с использованием оператора: 119

CREATE TABLE OF TYPE ; У типизированной таблицы в IUS имелся один столбец соответствующего составного типа, но в дальнейшем работа с полями значений строк этой таблицы (с точностью до синтаксических деталей) производилась точно так же, как если бы эти поля являлись столбцами таблицы. К типам записей и таблицам в IUS мог применяться механизм наследования. Поддерживалось только одиночное наследование, то есть число супертипов любого типа или супертаблиц любой таблицы не могло быть больше единицы, но у любого типа могло существовать произвольное число подтипов. Все функции, определенные для супертипа (обратите внимание, что в IUS не поддерживалось понятие методов, или операций определяемого пользователем типа), автоматически распространялись на все его подтипы, т.е. были применимы к любым значениям любого подтипа этого супертипа (другими словами, поддерживалась так называемая семантика включения). В то же время, для подтипов могли определяться свои функции, как новые, дополняющие функциональность, так и модифицированные, изменяющие функциональность, унаследованную от предка. В последнем случае имело место перекрытие функций и, естественно, требовалось отложенное связывание. Значения подтипов могли использоваться почти везде, где было разрешено употребление значений их супертипов. Единственное ограничение возникало при отведении памяти и хранении значений. Здесь соответствие типов должно было быть точным. Наследование таблиц являлось развитием концепции наследования типов. В иерархии наследования могли участвовать только типизированные таблицы, типы которых (типы записи) образуют параллельную иерархию. Однако, кроме столбцов супертаблиц, подтаблицы наследовали ограничения целостности (первичные ключи, уникальность, ссылочные ограничения), опции хранения, триггеры, индексы и методы доступа. При определении подтаблиц некоторые свойства супертаблиц можно было переопределять. В частности, для подтаблицы можно было определить собственную опцию хранения. Отношение наследования между таблицами являлось динамическим в том смысле, что, если изменялись наследуемые характеристики супертаблиц, то это немедленно отражалось и на подтаблицах 120

(как на прямых наследниках, так и отделенных несколькими уровнями иерархии). В IUS операции SELECT, UPDATE и DELETE, примененные к супертаблице, распространяются также и на все ее подтаблицы. Если требовалось ограничить запрос ровно одной супертаблицей, следовало употребить в запросе конструкцию ONLY.

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

3.1.3.2. Типы коллекций

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

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

CREATE TYPE SET NOT NULL; Поскольку по определению все элементы множества должны быть различны, ни в одно значение типа множества не могло входить неопределенное значение. Тип элементов множества мог задаваться именем типа для предопределенных или ранее определенных типов данных или определяться «по месту» для множеств, состоящих из элементов типа записи. Типы мультимножеств определялись с помощью конструкции:

CREATE TYPE MULTISET NOT NULL; Хотя по определению среди элементов мультимножества могут содержаться дубликаты, в IUS значения типа мультимножества, как и значения-множества не могли содержать неопределенных значений. Значения типа множества и мультимножества можно было использовать после предиката IN в разделе WHERE оператора SELECT. К этим значениям была применима функция CARDINALITY, возвращающая число элементов. Средствами прямого SQL можно было осуществлять доступ к значенияммножествам (и мультимножествам) только как к единому целому. Доступ к элементам множества был возможен только при использовании встраиваемого SQL IUS или языка определения хранимых процедур (SPL). Основная идея состояла в том, что множество представлялось в виде производной таблицы, каждая строка которой содержала один элемент множества. Любую операцию над множествами можно было выразить в терминах реляционных операций над производными таблицами. Список в IUS являлся упорядоченным набором элементов, в котором допускалось наличие дубликатов. Список отличается от мультимножества тем, что для каждого элемента списка имеется порядковый номер (нумерация начинается с единицы). Определение типа списка выглядит следующим образом:

CREATE TYPE LIST NOT NULL; 121

3.1.4. Модули DataBlade

3.2. Oracle8 Компания Oracle выпустила свою первую ОРСУБД Oracle8 в июне 1997 г. Эта система во многом базировалась на возможностях СУБД Oracle 7.3, которая, по моему мнению, была одним из наиболее удачных продуктов компании Oracle. Существенные дополнения к объектно-реляционным возможностям Oracle8 появились лишь в системе Oracle 9i (2002 г.). Здесь мы ограничимся обсуждением свойств Oracle8. Заметим, что Oracle8 было посвящено не слишком много публикаций, доступных на русском языке. Пожалуй, можно рекомендовать только [6].

3.2.1. Объектные типы и объектные таблицы Объектные типы в Oracle8 являлись аналогом типа записи в IUS. Объектный тип данных определялся в следующем синтаксисе:

CREATE TYPE AS OBJECT ( , . . . ); Как и в IUS, для доступа к отдельным полям значений объектных типов использовалась точечная нотация.

3.2.1.1. Методы объектных типов В Oracle 8i при определении объектного типа, помимо спецификации структуры значений этого типа, можно было определить и набор методов данного типа. Методы представляли собой функции, написанные на PL/SQL, Java, C или другом языке и сохраненные в базе данных или вне ее (при наличии регистрации в базе данных). 122

Методы объектного типа разбивались на три категории: методы-члены, статические методы и методы сравнения. Методы-члены вызывались в нотации: . ( список_параметров ). У них имелся неявный параметр SELF, и они могли обращаться к значениям атрибутов объекта. Под термином объект здесь понимается строка объектной таблицы. Как правило, именем объекта являлось имя объектной таблицы или ее псевдонима, используемые в операторе выборки SQL. Статические методы вызывались в нотации . ( список_параметров ) и не могли обращаться к значениям атрибутов конкретных объектов. Методы сравнения служили для сравнения экземпляров объектов. Сравнение объектов могло производиться с помощью методов вида MAP или вида ORDER. Метод типа MAP принимает в качестве параметра объект некоторого объектного типа, а возвращает значение одного из встроенных типов, которое может использоваться в операциях сравнения и сортировки. Таким образом, этот метод выполняет отображение объекта на значение одного из встроенных типов. Метод типа ORDER сравнивает два объекта и возвращает –1, если первый объект меньше второго, 0, если объекты равны, и 1, если первый объект больше второго. Если при определении объектного типа метод сравнения не задавался, то объекты этого типа можно было сравнивать только на равенство/неравенство, причем объекты не должны были содержать элементов типа LOB. Тогда объекты считались равными в том и только в том случае, когда все их элементы не содержали неопределенных значений, и значения соответствующих элементов совпадали. У каждого объектного типа имелся определяемый системой методконструктор, который создавал новый объект этого типа (строку типизированной таблицы) и присваивал начальные значения его атрибутам. Метод-конструктор – это функция, которая возвращает объект данного типа. Имя метода-конструктора совпадает с именем объектного типа, имена и типы параметров конструктора – с именами и типами атрибутов объектного типа.

в той же форме, как это делалось в IUS, но без поддержки параллельной иерархии наследования объектных типов. В Oracle8 строки объектных таблиц назывались строчными объектами (row objects). Для всех строчных объектов обеспечивалась возможность уникальной идентификации. Использовалось понятие объектного идентификатора, и столбец любой таблицы можно было определить на встроенном типе REF. Значения этого столбца являлись своего рода указателями на строчные объекты той же самой или другой объектной таблицы. В качестве значений типа REF использовались уникальные идентификаторы строк таблиц RowID, которые в Oracle почти напрямую адресуют строки во внешней памяти. Следует отметить, что в Oracle (в отличие от других СУБД, в частности, DB2) исторически допускалось использование RowID на уровне пользователя. В соответствии с идеологией Oracle, в любой таблице (в том числе, объектной) присутствует неявный столбец, содержащий RowID каждой строки. Считается, что REF-значение, указывающее на некоторый строчный объект, и сам этот строчный объект имеют разные, хотя и связные типы данных. Система не брала на себя ответственность за согласование ссылок; за это отвечали пользователи. В SQL Oracle8 поддерживалась встроенная функция REF, позволяющая получить значение объектного идентификатора указанной строки. Наличие в объектной таблице столбцов ссылочного типа позволяло в ряде случаев упрощать формулировку запросов (в духе путевых выражений ODMG). Кроме того, как утверждает компания Oracle, при явном использовании объектных идентификаторов (т.е. RowID) удается повысить эффективности выполнения ряда запросов.

3.2.2. Типы коллекций в Oracle8 В Oracle8 поддерживались две разновидности типов коллекций: табличные типы (table types) и типы массивов (array types). Значениями каждого типа коллекции являлись коллекции (таблицы или массивы) элементов одного и того же типа (типа элемента). Тип элемента мог быть встроенным или объектным типом, но не типом коллекции.

3.2.2.1. Табличный тип

3.2.1.2. Объектные таблицы, ссылочные типы

Табличный тип создавался конструкцией следующего вида:

Объектной таблицей в Oracle8 называлась таблица, строки которой имеют объектный тип. Синтаксис определения был близок к синтаксису определения типизированных таблиц в IUS. В Oracle8 не поддерживалось наследование (ни типов, ни таблиц), однако уже в Oracle8i (начало 1998 г.) появилась возможность наследования таблиц почти

CREATE TYPE AS TABLE OF ;

123

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

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

3.2.2.2. Тип массива Вторая, менее привязанная к особенностям реализации, разновидность типов коллекций в Oracle8 называлась VARRAY, что вполне соответствует стандарту SQL:1999 и означает массив переменного размера (varying-length array). При определении типа массива указываются имя типа, тип элементов и максимальное число элементов, которые может содержать значение определяемого типа. В отличие от значений табличного типа, для элементов значений типа массива поддерживается порядок. Для определения типа массива использовалась следующая синтаксическая конструкция: CREATE TYPE AS VARRAY () OF ; Как и в случае с множествами (и мультимножествами) в IUS, на уровне прямого SQL Oracle8 можно было работать только с массивами целиком. Однако существовала возможность привести в запросе (или другом операторе SQL) тип массива к табличному типу. Как уже говорилось, в Oracle8 отсутствовала поддержка наследования, и запрещалось определение типов коллекций с использованием ранее определенных типов коллекций. Соответствующие возможности появились только в Oracle 9i (2002 г.).

3.3. DB2 Universal Database Компания IBM последней, после Informix и Oracle, объявила свой объектнореляционный продукт (в конце 1998 г.) и назвала его DB2 Universal Database (UDB). Однако, как стало ясно немного позже, базовые идеи объектнореляционных расширений были заложены еще в продукте компании IBM DB2 for Common Servers, выпущенном в 1995 г. Эти идеи описаны в статье [7]. Насколько мне известно, первой публикацией на русском языке, посвященной непосредственно DB2 Universal Database, является [8].

3.3.1. Базовые идеи объектно-реляционных расширений DB2 Традиционные возможности языка SQL, связанные с типами данных и поиском, недостаточны для нового поколения мультимедийных приложений баз данных. Требования таких приложений настолько различны, что не могут 125

быть удовлетворены любым набором предопределенных расширений языка. Требуются средства определения пользователями новых типов данных и функций над ними. Другим требованием современных приложений баз данных является возможность хранения правил, делающих данные более активными и позволяющих системе баз данных автоматически выполнять проверки корректности данных и автоматизировать многие бизнес-процедуры. Активизация данных дает возможность приложениям совместно использовать не только сами данные, но и поведение данных. Обе указанные возможности позволяют повысить ценность хранимых данных за счет расширения их семантического содержимого. Тенденция к повышению роли семантического содержимого хранимых данных является наиболее важной в современном управлении базами данных. В соответствии с этой тенденцией реляционные системы баз данных расширяются в двух направлениях:  добавлении объектной инфраструктуры к самой системе баз данных в виде поддержки определяемых пользователями типов данных, функций и правил;  построении поверх этой инфраструктуры реляционных расширителей, которые поддерживают специализированные приложения, такие как выборка изображений, развитый текстовый поиск, географические приложения. Система, которая обеспечивает объектную инфраструктуру и набор реляционных расширителей, называется объектно-реляционной.

3.3.1.1. Объектная инфраструктура В DB2 поддерживались три типа данных для хранения больших объектов: BLOB для бинарных объектов, CLOB для символьных строк и DBCLOB для строк, в которых используются двухбайтовые наборы символов. Для каждого из этих типов данных можно было хранить объекты объемом до 2 Гбт. Подсистема восстановления DB2 давала возможность создателю таблицы выключать обычную журнализацию изменений столбцов с большими объектами. При выключенной журнализации по отношению к таким столбцам гарантировалась согласованность транзакций, но столбец не мог участвовать в процедуре прямого восстановления. Пользователи DB2 имели возможность создания собственных функций с использованием языков C, C++ и Basic. Вызовы определяемых пользователями функций (User-Defined Functions, UDF) могли использоваться в любом выражении SQL, где предполагалось наличие скалярного значения. В SQL DB2 можно было перегружать имя функции, т.е. определять несколько функций с одним именем и разными типами параметров. При обработке вызова функции DB2 вызывала функцию, сигнатура которой строго соответствовала типам аргументов вызова. 126

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

3.3.1.2. Реляционные расширители На основе представленной выше объектной инфраструктуры можно было создавать реляционные расширители (extender) для поддержки конкретных прикладных областей. Еще до выпуска DB2 UDB поддерживались расширители Text Extender для быстрого контекстного поиска в больших текстовых документах; Image Extender для хранения и выборки изображений, представленных в разных форматах; Video Extender для хранения и выборки видео-последовательностей; Audio Extender для хранения и выборки аудио-клипов и т.д. Все эти возможности были доступны в DB2 for Common Servers с июля 1995 г. В течение следующих двух лет в лабораториях IBM производилась интенсивная разработка дополнительных объектно-реляционных средств, включая абстрактные типы данных с наследованием; UDF с телом, написанным на SQL; UDF, результатом которых являются таблицы; возможность обращаться со строкой таблицы как с объектом, возможно содержащим ссылки на другие строки-объекты; дополнительные расширители для таких специализированных типов данных, как временные ряды и географические данные.

3.3.2. Дополнительные объектно-реляционные возможности DB2 UDB 3.3.2.1. Структура, поведение, наследование Для некоторых типов данных имеет смысл трактовать объект как именованный набор атрибутов. Этот вид определяемого пользователями типа в терминологии IBM называется структурным типом. Механизм 127

структурных типов с самого начала включал не только возможность определения типов со структурой, но и средства определения иерархий типов и иерархий таблиц. Кроме того, допускалось использование «ссылок» для определения связей между объектами и навигации от одного объекта к другому. С самого начала для определения поведения структурного типа можно было использовать UDF. Однако в DB2 Version 7 появилась возможность определения методов объектов. Методы могут быть написаны на SQL или на внешнем языке, например, на Java или C. Но методы всегда ассоциируются с некоторым структурным типом, и их вызовы производятся в синтаксисе, отличном от синтаксиса вызова UDF.

3.3.2.2. Создание иерархий типизированных таблиц Иерархии таблиц используются для хранения объектов и для обеспечения возможности изменять эти объекты на уровне SQL. С концептуальной точки зрения, в иерархии таблиц отражается соответствующая иерархия типов. Однако типы, подобно библиотекам классов, могут использоваться в различных контекстах, поэтому не все типы из иерархии типов обязаны присутствовать в соответствующей иерархии таблиц. Единственным требованием является то, что при образовании иерархии таблиц должно использоваться подмножество ассоциированной иерархии типов. При определении типизированной таблицы (аналог типизированной таблицы IUS или объектной таблицы Oracle8) нужно явно специфицировать дополнительный столбец, в котором будут храниться значения объектных идентификаторов (OID) каждого объекта (строки), содержащейся в таблице. Значения OID в DB2 могут как генерироваться системой (в DB2 это совсем не RowID, как в Oracle8, а некоторые абстрактные идентификаторы), так и задаваться пользователями при занесении строки в типизированную таблицу. Столбец OID создается как первый столбец таблицы, и за ним следуют столбцы, соответствующие атрибутам типа таблицы. Объектные идентификаторы используются в операциях разыменования (dereference), т.е. обеспечивают возможность добраться до строки по ссылке и преобразовать ее в экземпляр (значение) структурного типа. В иерархии таблиц поддерживается семантика включения, т.е. все строки подтаблиц доступны через запрос, адресуемый к их супертаблице. Естественно, запрос к супертаблице может выдать только значения столбцов, определенных в этой супертаблице. Однако имеется возможность формулировки запроса к супертаблице с внешним объединением строк всех подтаблиц. Имеется и обратная возможность. Используя в запросе ключевое слово ONLY, можно ограничить оператор выборки набором строк, непосредственно принадлежащих супертаблице. Как и в Oracle, в запросах на DB2 SQL можно использовать путевые выражения, но не в «точечной», а в «стрелочной» нотации. 128

Заметим, что когда-то разработчики DB2 UDB собирались включить в систему и средства работы с типами коллекций, однако, насколько известно автору, этого не произошло до сих пор.

4. Коротко о предпосылках ОРСУБД До появления 10 лет назад ОРСУБД ведущих компаний термин «объектнореляционная СУБД» связывался с системами Postges-Illustra и UniSQL, разработанными под руководством Майкла Стоунбрейкера и Вона Кима соответственно. Про первое направление уже достаточно говорилось выше, поскольку оно лежит в основе IUS. Повторим лишь, что до основания компании Illustra сам Стоунбрейкер не использовал этого термина. Например, в [9] говорилось, что в модели данных Postges сочетаются объектные и расширенные реляционные черты, но авторы не берутся присвоить ей какоелибо отдельное название. С другой стороны, Вон Ким сразу стал называть СУБД UniSQL «единой реляционной и объектно-ориентированной системой баз данных» [10]. В соответствии с подходом UniSQL, в ОРСУБД должны поддерживаться следующие возможности [11]:  n-мерное объектно-ориентированное моделирование;  двухмерное реляционное моделирование;  наследование;  инкапсуляция;  постоянство существования объектов (object persistence);  композиция классов;  полиморфизм;  навигационный доступ к объектам;  реляционный доступ (соединения);  непроцедурный доступ через запросы;  интерфейсы для традиционных языков третьего поколения;  интерфейсы для объектных языков третьего поколения;  интерфейсы для языков четвертого поколения;  независимое от языков хранение данных;  независимость служб баз данных от файловых систем;  поддержка оперативных служб СУБД. Как отмечалось в [11], единая модель данных UniSQL опирается на следующее наблюдение. Если взять объектно-ориентированную модель данных и удалить из нее понятия наследования и инкапсуляции, то останется сетевая модель данных*. Далее, если удалить из нее понятия указателей и коллекций, то останется реляционная модель данных. В этом наблюдении *

В смысле CODASYL, см., например, [12]. 129

имеется доля разумного смысла с учетом недостаточной точности определения объектно-ориентированной модели данных. В следующем разделе будет обсуждаться подход к сочетанию реляционных и объектных свойств в модели данных, представленной в современном стандарте языка SQL, и я приведу собственную точку зрения по этому поводу. Пожалуй, наиболее существенные различия в подходах Майкла Стоунбрейкера и Вона Кима состояли в выборе отправной точки для построения объектно-ориентированных систем баз данных и в акцентах, которые делались при выполнении этой работы. Стоунбрейкер двигался от реляционной модели данных и от собственных реализаций СУБД, основанных на этой модели. Для него было наиболее важно сохранить в объектнореляционной системе возможности реляционных систем, добавив, по мере возможности, средства, свойственные объектным системам. Понятно, что этот подход оказался привлекательным для компаний, производивших SQLориентированные СУБД, поскольку позволял им наращивать функциональные возможности своих систем без потребности в их коренной перестройке. Вон Ким до создания СУБД UniSQL, в частности, активно занимался проектированием и разработкой чисто объектно-ориентированных СУБД. Под его руководством было разработано семейство ООСУБД Orion [13]. Поэтому для него было естественно подходить к решению проблемы единой объектнореляционной модели данных с позиций объектно-ориентированного мира. Как говорится в [10], ядро UniSQL проектировалось с целью полной поддержки надмножества базовой объектной модели (Core Object Model, COM) консорциума Object Management Group**. Реляционные свойства обеспечивались, фактически, путем специального использования объектных возможностей системы. По пути UniSQL впоследствии пошли многие компании, производившие не SQL-ориентированные (в частности, объектноориентированные) СУБД, для обеспечения поддержки языка SQL. Тем не менее, подход Вона Кима не оказал существенного влияния на «основной поток» ведущих коммерческих СУБД. С методологической точки зрения на развитие основного объектнореляционного подхода и соответствующих средств, специфицированных в стандарте языка SQL, важнейшее влияние оказал Манифест систем баз данных третьего поколения, опубликованный группой авторов под очевидным руководством Майкла Стоунбрейкера в 1990 г. [3]. В этом документе постулировались три основных принципа систем следующего поколения: **

Модель данных COM лежала в основе архитектуры CORBA и являлась в начале 1990-х гг. единственной объектной моделью данных, для которой существовала независимая от производителей спецификация. Впоследствии на модели COM во многом основывалась стандартная объектная модель данных ODMG (Object Data Management Group) [15]. 130

 помимо традиционных услуг по управлению данными, СУБД третьего поколения должны обеспечивать поддержку более богатых структур объектов и правил;  СУБД третьего поколения должны включить в себя СУБД второго поколения;  СУБД третьего поколения должны быть открыты для других подсистем. Эти принципы развивались в тринадцати технических предложениях, включающих обеспечение развитой системы типов с поддержкой наследования и инкапсуляции. Если внимательно посмотреть на стандарты SQL:1999 и SQL:2003 [1,2], а также на возможности современных версий СУБД DB2 и Oracle, то можно увидеть отражение в них всех принципов и предложений Манифеста систем баз данных третьего поколения. Другой вопрос, насколько эти принципы и предложения можно считать объектными? Мы обсудим этот вопрос в контексте языка SQL в следующем разделе.

5. ОРСУБД и стандарт языка SQL В процессе стандартизации языка баз данных SQL можно выделить, по моему мнению, три основных этапа. Первый этап начался в середине 1980-х гг. и завершился принятием международного стандарта SQL/89, наиболее важным достижением которого явилась языковая спецификация базовых средств запросов и механизмов ссылочной целостности. Результатом второго этапа явилось принятие стандарта SQL/92, в котором были полностью специфицированы средства определения и эволюции схемы базы данных, поддержки ссылочной целостности, манипулирования данными, связывания SQL с языками программирования и ряд других возможностей, позволяющих использовать стандарт SQL для реализации полнофункциональной РСУБД. С точки зрения основной темы данной статьи для нас основной интерес представляет третий этап, важным промежуточным финишем которого явилось появление стандарта SQL:1999, развитого и уточненного в стандарте SQL:2003. Сейчас (в феврале 2007 г.) трудно сказать, закончился ли этот этап и происходит ли новый этап, связанный с интеграцией в SQL средств управления XML-данными. Ответ на этот вопрос можно будет дать только после принятия следующего стандарта. В этой статье в стандартах SQL:1999 и SQL:2003 (на которые далее я буду обобщенно ссылаться, как на стандарт SQL) меня, главным образом, интересуют система типов SQL, возможности определения типов пользователями и средства определения и использования так называемых типизированных таблиц (typed tables), составляющие, по мнению разработчиков стандарта, объектную модель SQL.

131

5.1. SQL как модель данных Конечно, любой вариант стандарта языка SQL можно было трактовать как определение модели данных в соответствии с критериями Эдгара Кодда [16]. Для полноты картины напомню, что по Кодду модель данных представляет собой некий абстрактный эталон, которому должны соответствовать все реализации, претендующие на соответствие общей модели. В спецификации модели данных Кодд выделял структурную, целостную и манипуляционную составляющие, определяющие, соответственно:  структуры данных, которые могут существовать в базах данных, отвечающих модели;  базовые ограничения целостности, определение и поддержка которых должны обеспечиваться в системах баз данных, поддерживающих эту модель;  средства манипулирования данными, задающие критерий выразительной мощности любого конкретного языка баз данных, который может поддерживаться в соответствующих СУБД. Для реляционной модели данных в структурной части модели говорится, что единственной «родовой» структурой данных является n-арное отношение, атрибуты которого содержат атомарные значения. В целостной части требуется поддержка целостности сущности (наличие у любого отношения хотя бы одного возможного ключа) и целостности ссылок (недопущение внешних ключей, содержащих не неопределенное значение, для которого отсутствует совпадающее с ним значение возможного ключа в отношении, в которое ведет ссылка). Наконец, в манипуляционной составляющей реляционной модели данных специфицировались эквивалентные механизмы реляционной алгебры и реляционного исчисления. Достаточно очевидно, что:  любой из перечисленных выше стандартов языка SQL определяет некоторую модель данных;  с появлением каждого следующего варианта стандарта языка SQL соответствующая модель данных дополняется и уточняется;  наконец (и это самое важное!), модель данных, определяемая языком SQL, никогда (!) не была и не является реляционной. Действительно, начиная со стандарта SQL/89 было понятно, что SQLориентированная база данных состоит из таблиц, в столбцах которых могут содержаться данные типов, специфицированных в стандарте. Говорилось, что в таблицах могут определяться первичный и возможный ключи, и в этом случае СУБД должна поддерживать уникальность их значений. Некоторым образом требовалась поддержка ссылочной целостности. Наконец, в качестве 132

«абстрактного» механизма манипулирования данными выступали средства самого языка SQL. С другой стороны, только в стандарте SQL/92 были явно введены конструкции определения базовых таблиц, а тем самым, и возможности определения первичных и возможных ключей. Только в стандарте SQL:1999 был специфицирован полный набор параметризуемых, генерируемых и определяемых пользователями типов данных, значения которых могут присутствовать в столбцах таблиц SQL-ориентированных баз данных. По мере развития стандарта расширялись и уточнялись средства поддержки ссылочной целостности и манипулирования данными и т.д. Наконец, начиная с SQL/89, определение хотя бы одного возможного ключа в таблице было необязательным, так что в таких таблицах могли присутствовать строки-дубликаты, они не являлись множествами строк; следовательно, они не были аналогами отношений реляционной модели данных. В заголовках таблиц присутствовал неявный порядок имен столбцов, следовательно, они не являлись аналогами заголовков отношений реляционной модели данных. В столбцах таблиц, наряду с типизированными значениями, могли храниться нетипизированные неопределенные значения, вызывающие необходимость в использовании трехзначной логики и приводящие к иногда парадоксальным ситуациям [17]. Трактовка стандарта SQL как спецификации некоторой особой модели данных (модели данных SQL) стала действительно актуальной после появления стандарта SQL:1999. До этого достаточно было говорить, что язык SQL во многом следует реляционной модели данных, но с некоторыми отклонениями, которые следует иметь в виду. Однако появление «объектных расширений» в SQL:1999 («объектность» этих расширений мы обсудим в следующем подразделе), в особенности, полной системы типов, во-первых, делает законченной собственную модель SQL, во-вторых, еще больше отдаляет модель SQL от классической реляционной модели данных Кодда и, в третьих, создает потребность в сопоставлении модели SQL с объектной моделью ODMG [15] и «истинно реляционной» моделью Кристофера Дейта и Хью Дарвена [18]*. Понимание отличий модели данных SQL от реляционной модели данных очень важно для проектировщиков, администраторов и разработчиков приложений SQL-ориентированных баз данных. Похоже, что сегодняшняя *

Замечу, что некоторое сопоставление этих моделей делается в [18] и вышедшем в 2006 г. новым изданием этой книги [19]. Однако авторы этих книг не трактуют стандарт SQL как модель данных и вообще относятся к SQL подчеркнуто и категорически отрицательно. Поэтому, с моей точки зрения, сравнения, приводимые в [18, 19] не вполне объективны. Так что потребность в объективном сопоставлении понятий, возможностей и недостатков этих трех моделей данных остается. 133

модель данных SQL включает классическую реляционную модель данных [16], хотя расходится в части механизма типов данных с «истинно реляционной» моделью [18]. Очевидным преимуществом классической реляционной модели данных является ее собственная простота и следующая из нее простота баз данных и их приложений. Поэтому при использовании SQL нужно явно отдавать себе отчет в реальной потребности использования возможностей, выходящих за пределы классической реляционной модели данных.

5.2. Объектная подмодель SQL В самом стандарте языка SQL, естественно, вообще ничего не говорится о моделях данных. Однако главный редактор стандарта SQL Джим Мелтон в [1] утверждает, что объектная подмодель SQL включает два основных отличительных набора механизмов: средства определения и использования структурных типов данных (User Defined Type – UDT ) и типизированных таблиц (typed table). Первый компонент позволяет определять новые типы данных, которые могут быть гораздо более сложными, чем встроенные типы данных языка SQL. При определении структурного UDT требуется специфицировать не только содержащиеся в нем элементы данных, но и семантику типа данных, т.е. его поведение на основе интерфейса вызовов методов. UDT являются полностью инкапсулированными. Доступ к значениями UDT возможен только через методы этого типа. Для каждого атрибута UDT автоматически определяются два метода: наблюдатель (observer) и мутатор (mutator). Метод-наблюдатель применятся к значению UDT и возвращает значение соответствующего атрибута этого структурного значения. Метод-мутатор действует над местоположением (столбцом строки некоторой таблицы, переменной или параметром) значения UDT и заменяет это структурное значение новым значением с указанным значением соответствующего атрибута. Синтаксические правила вызова методов-наблюдателя и мутатора таковы, что позволяют манипулировать с атрибутами значений UDT в привычной «точечной» нотации. Для определения структурных UDT поддерживается механизм одиночного наследования. При определении подтипа можно добавлять к структуре супертипа новые атрибуты, специфицировать новые методы или изменять реализацию методов супертипа (с сохранением сигнатуры). Соответственно, поддерживаются полиморфизм по включению (значение любого UDT является значением любого своего супертипа) и отложенное связывание. Второй компонент – типизированные таблицы – позволяет определять таблицы, строки которых являются экземплярами (или значениями) UDT , с которым явно ассоциируется таблица. При определении типизированной таблицы можно объявить ее подтаблицей некоторой другой типизированной таблицы. Супертаблица должна быть ассоциирована со структурным типом, 134

являющимся непосредственным супертипом определяемой подтаблицы. Каждый столбец указанной супертаблицы наследуется подтаблицей; наследуются и характеристики столбцов супертаблицы – значения по умолчанию, ограничения целостности и т.д. Эти столбцы называются унаследованными столбцами подтаблицы, и они соответствуют атрибутам UDT подтаблицы, унаследованным от UDT супертаблицы. Кроме того, подтаблица будет содержать по одному столбцу для каждого собственного атрибута ассоциированного структурного типа. Такие столбцы подтаблицы называются заново определенными. В определении максимальной супертаблицы (не являющейся подтаблицей какой-либо другой супертаблицы) должна присутствовать спецификация «самоссылающегося» (self -referencing ) столбца, и самоссылающийся столбец, определенный в максимальной супертаблице, наследуется любой ее подтаблицей. Эта спецификация не может входить в определение подтаблицы. Значения самоссылающегося столбца относятся к ссылочному типу, ассоциированному с UDT, на котором определена данная типизированная таблица. Значения ссылочного типа, или ссылочные значения могут генерироваться одним из трех способов (указываемых при определении UDT):  задаваться приложением как значения некоторого встроенного типа SQL каждый раз при сохранении экземпляра структурного типа как строки типизированной таблицы;  порождаться из одного или нескольких атрибутов UDT;  автоматически генерироваться системой. Любой ссылочный тип можно использовать для объявления типа любого местоположения, в том числе, столбца другой типизированной или обычной таблицы. Поскольку любое действующее ссылочное значение является уникальным идентификатором соответствующей строки типизированной таблицы, в объектной подмодели SQL оно считается аналогом объектного идентификатора в обычных объектных моделях (в частности, в модели ODMG), и в SQL-запросах можно использовать «стрелочную» нотацию для перехода от одного «объекта» к другому по ссылочному значению. При использовании этой возможности SQL-запросы почти неотличимы синтаксически от запросов на языке OQL [15]. Эта синтаксическая близость может привести к впечатлению о близости самих объектных моделей SQL и ODMG. Обманчивость этого впечатления обосновывается в [20]. Я не буду говорить об этом в данной статье, хотя некоторые утверждения в [20] уже кажутся мне слишком категоричными. Но здесь мне хочется затронуть другой вопрос: насколько гармонирует объектная подмодель SQL с общей моделью данных SQL? Заметим, что средства определения структурных UDT можно считать частью стандарта SQL, относящегося к системе типов данных. В стандарте SQL поддерживаются: 135

   

параметризуемые типы точных и приближенных чисел; параметризуемые типы символьных и битовых строк; темпоральные типы данных (дата-время, интервал); генерируемые типы коллекций (множества, мультимножества, массивы);  анонимные строчные типы;  индивидуальные и структурные UDT;  ссылочные типы.* При определении типа коллекции можно использовать любой тип элементов, включая типы коллекций и UDT. Элементы анонимных строчных типов и атрибуты структурных UDT могут также иметь любой тип данных. Для значений любого типа данных определена операция сравнения по равенству, так что с точки зрения модели данных SQL осмысленными являются столбцы, определенные на любом типе данных (по крайней мере, работают наиболее важные в модели SQL, как и в реляционной модели, операции экви- и естественного соединения). Так что система типов SQL вполне гармонична модели данных SQL. Более того, я не стал бы считать, что в системе типов SQL имеются «объектные расширения»: подобные средства свойственны любому полнотиповому языку, не обязательно объектно-ориентированному. Вообще говоря, нет ничего особенно «объектного» и в типизированных таблицах. По сути дела, объявляется таблица с двумя столбцами, один из которых определен на структурном UDT, а другой содержит уникальные идентификаторы (суррогатные, если они генерируются системой). По сути дела, «объектность» в стандарте SQL появляется, когда мы начинаем считать строки типизированной таблицы объектами, а идентификаторы этих строк объектными идентификаторами. В этом случае на свет выходит «стрелочная нотация», заменяющая эквисоединения. Но мы должны отдавать себе отчет, что это всего лишь синтаксическая замена: чтобы добраться от строки одной таблицы до строки другой таблицы по ссылочному значению, требуется, чтобы это ссылочное значение хранилось в обеих строках, т.е. переход от одной строки к другой делается, фактически, путем эквисоединения. Таким образом, «объектные расширения» SQL не выводят язык за пределы общей модели SQL. При этом обеспечиваются функциональные возможности, которые специалисты из объектного мира считают «объектными» (см., например, разд. 4 относительно подхода Вона Кима к организации UniSQL).

6. Проблемы и перспективы ОРСУБД Как отмечалось во введении, в последние годы про ОРСУБД говорят и пишут очень мало. Я обсуждал вопросы использования расширенных возможностей *

В этом списке умышленно отсутствует тип данных XML, поскольку соответствующие аспекты языка SQL в данной статье не рассматривается. 136

SQL со многими разработчиками приложений, администраторами баз данных, сотрудниками ведущих компаний-производителей СУБД и пришел к следующим выводам. Для большинства практических разработчиков приложений расширенные возможности SQL ограничиваются средствами серверного программирования с использованием хранимых процедур и функций. Мне не удалось найти пример недавно созданного независимыми разработчиками приложения баз данных, для которого в базе данных определялся бы специальный структурный UDT. Тем более, мне неизвестны базы данных, содержащие типизированные таблицы. Казалось бы, естественно использовать расширенные возможности ОРСУБД самими компаниями, производящими эти системы, для включения в них новых функциональных возможностей (как это и происходило 10 лет назад). Однако и таких примеров крайне мало. Например, я был очень обрадован, узнав, что специалисты компании Oracle воспользовались объектными расширениями SQL для реализации в Oracle 10g функциональных возможностей управления многомерными данными, которые ранее поддерживались отдельным продуктом Oracle Express Server [21]. Почему же пользователи ОРСУБД и разработчики приложений пренебрегают развитыми средствами, которые обеспечиваются в этих системах? Можно было бы подумать, что людей из «реляционного» мира SQL отпугивают новые «объектные» возможности. Но в разд. 5 мы видели, что «объектные» расширения SQL совсем не являются объектными и не меняют модель данных SQL. Похоже, что причина кроется совсем в другом, а именно, в излишне обширном наборе возможностей. Расширенные возможности SQL, в особенности, средства серверного программирования, обеспечивающие возможности определения UDT, хранимых процедур и функций, триггеров и т.д. позволяют переносить на сервер баз данных все большую часть логики приложений. Это в значительной степени противоречит учению Эвгара Кодда, в котором обосновывалась целесообразность независимости базы данных от приложений. Независимость базы данных от приложений часто выглядит очень привлекательной идеей, но для ее применения разумно отказаться от многих расширений SQL. Кроме того, даже если не принимать во внимание упомянутую идею, при проектировании приложения базы данных имеется три альтернативы: можно реализовать логику приложения на стороне клиента, на сервере приложений и на сервере баз данных. Очевидно, что каждая альтернатива имеет право на жизнь, и каждая из них может оказаться выигрышной в конкретной ситуации. Однако отсутствует методология, не говоря уже про технологию, выбора наиболее выгодного проектного решения. Для расширения области использования ОРСУБД требуются дополнительные исследования и разработки в этом направлении. 137

Другой проблемой, не связанной с возможностями серверной реализации логики приложений, является использование в базах данных типов коллекций. Поддержка в стандарте SQL типов мультимножеств, элементами которых могут быть значения анонимных строчных типов, обеспечивает теперь возможность определения вложенных таблиц с произвольным (теоретически, неограниченным) уровнем вложенности. Поскольку все значения, хранимые в базе данных, продолжают оставаться строго типизированными, такая возможность не противоречит базовому требованию первой нормальной формы, унаследованному из реляционной модели данных, но, по существу, обеспечивает подход к прямому моделированию иерархических структур. Разработчики приложений баз данных в течение многих лет порицали SQL за отсутствие прямой поддержки иерархий. Теперь эта возможность появилась и многих поставила в тупик. В каких случаях действительно выгодно пользоваться вложенными таблицами? Нужно ли разработчикам приложений понимать, что на уровне хранения данных в реализации SQLориентированных СУБД, скорее всего, физическая вложенность поддерживаться не будет? В действительности, проблема выбора способа представления иерархических данных свойственна не только современному SQL, аналогичные проблемы возникают, например, и при проектировании баз XML-данных. Здесь тоже требуются исследования с целью выработки обоснованных рекомендаций и методологий проектирования*. Другими словами, аскетичность подхода Кодда, выраженная в классической реляционной модели данных, оказывается пока понятнее и полезнее богатства современной модели данных SQL (думаю, что это равно применимо к объектной модели ODMG и «истинно реляционной» модели Дейта и Дарвена). Для полноценного использования этого богатства требуются понятные и обоснованные методологии. Я думаю, что накопленный за 10 лет багаж объектных расширений, специфицированных в стандарте SQL и реализованных в передовых продуктах компаний IBM и Oracle, не должен бесславно пропасть. Это было бы нерационально, учитывая громадный объем человеческого труда, затраченного за создание этих расширений. Мне хочется надеяться, что с помощью исследовательского сообщества баз данных удастся решить упомянутые выше и другие проблемы и привлечь разработчиков к полноценному использованию возможностей ОРСУБД.

*

Замечу, что здесь не могут выручить средства концептуального моделирования баз данных, такие как E/R-диаграммы или диаграммы классов UML, поскольку в них также допускаются различные альтернативы моделирования иерархических данных. 138

7. Заключение Появление объектно-реляционного подхода к организации баз данных и СУБД явилось важным шагом на пути развития технологии баз данных. За 10 лет, прошедших с момента выхода первой коммерческой ОРСУБД, объектнореляционный подход, с одной стороны, приобрел зрелость, утвердился в спецификациях стандарта SQL, но, с другой стороны, так и не завоевал широкого распространения среди разработчиков приложений баз данных. В этой статье, посвященной юбилею ОРСУБД, были обсуждены история подхода, его современное состояние и проблемы, препятствующие его широкому использованию Литература [1] Jim Melton. Advanced SQL:1999. Understanding Object-Relational and Other Advanced Features. Morgan Kaufmann Publishers, 2003 [2] Сергей Кузнецов. Наиболее интересные новшества в стандарте SQL:2003. http://www.citforum.ru/database/sql/sql2003/, 2004 [3] M. Stonebraker, L. Rowe, B. Lindsay, J. Gray, M. Carey, M. Brodie, Ph. Bernstein, D. Beech. Third-Generation Data Base System Manifesto. Proc. IFIP WG 2.6 Conf. on Object-Oriented Databases, July 1990, ACM SIGMOD Record, 19, No. 3 (September 1990). (Имеется русский перевод: Стоунбрейкер М. и др. “Системы баз данных третьего поколения: Манифест”, СУБД, No. 2, 1995, http://old.osp.ru/dbms/1995/02/23.htm) [4] В.Галатенко, А.Гвоздев. Типы и структуры данных в Informix Universal Server. Jet Info/Информационный бюллетень, N 12-13, 1997, http://www.jetinfo.ru/1997/1213/1/article1.12-13.1997.html [5] А. Грачев. Объектно-реляционная СУБД Informix Universal Server. СУБД, N 1-2, 1998, http://old.osp.ru/dbms/1998/01-02/013.htm [6] В. Пржиялковский. Новые одежды знакомых СУБД: Объектная реальность, данная нам. СУБД, No. 2, 1995, http://old.osp.ru/dbms/1997/04/88.htm [7] Donald Chamberlin. Anatomy of an Object-Relational Database, DB2 Magazine, Winter 1996, Vol. 1, No. 1. (Имеется русский перевод: Д. Чемберлин. “Анатомия объектно-реляционных баз данных”, СУБД, No. 1-2, 1998, http://old.osp.ru/dbms/1998/01-02/003.htm ) [8] Н. Игнатович. База данных DB2 Universal Database. Материалы конференции «Корпоративные Базы Данных'1999», http://www.citforum.ru/seminars/cbd99/db2.shtml [9] Michael Stonebraker, Lawrence A. Rowe, Michael Hirohama: The Implementation of Postgres. IEEE Trans. Knowl. Data Eng. 2 (1), 1990 [10] Won Kim. UniSQL/X unified relational and object-oriented database system. ACM SIGMOD Record, 23 , No. 2 (June 1994) [11] Albert D 'Andrea and Phil Janus. UniSQL's next-generation object-relational database management system. ACM SIGMOD Record, 25 , No. 3 (September 1996) [12] М.Р. Когаловский. Энциклопедия технологий баз данных. – М.: Финансы и статистика, 2002. [13] Won Kim, Jorge F. Garza, Nathaniel Ballou, Darrell Woelk. Architecture of the ORION Next-Generation Database System. IEEE Trans. Knowledge and Data Eng., 2 (1), 1990 [14] OMG Core Object Model. http://www.objs.com/x3h7/omgcore.htm

139

[15] С.Д. Кузнецов. Три манифеста баз данных: ретроспектива и перспективы. Базы данных и информационные технологии XXI века. Материалы международной научной конференции. Москва, РГГУ, 2004, http://www.citforum.ru/database/articles/manifests/ [16] E. F. Codd: A Relational Model of Data for Large Shared Data Banks, CACM 13, No. 6 (June 1970). Republished in “Milestones of Research”, CACM 26, No. 1 (January 1982). (Имеется русский перевод: Кодд Е. А. “Реляционная модель для больших совместно используемых банков данных”, СУБД, No. 1, 1995, http://old.osp.ru/dbms/1995/01/01.htm) [17] Сергей Кузнецов. Дубликаты, неопределенные значения, первичные и возможные ключи и другие экзотические прелести языка SQL. СУБД, No. 3, 1997, http://www.citforum.ru/database/articles/art_5.shtml [18] К. Дейт, Хью Дарвен. Основы будущих систем баз данных. Третий манифест. – М: Янус-К, 2004 [19] C.J. Date and Hugh Darwen. Databases, Types, and the Relational Model. The Third Manifesto. Addison Wesley; 3 edition (February 24, 2006) [20] Сергей Кузнецов. Объектны» ли объектные расширения языка SQL? http://www.citforum.ru/database/articles/sql_odmg/, 2005 г. [21] Bud Endress, Hemant Verma. Leveraging Business Intelligence Tools with the OLAP option to the Oracle10g Database. http://www.oracle.com/technology/products/bi/olap/40261_leveragingtools.pdf

140

Семантическая реконсиляция прикладных данных на основе моделей 1 В.А. Семенов, С.Г. Ерошкин, А.А. Караулов, И.В. Энкович Аннотация. Рассматривается задача семантически корректной и функционально содержательной реконсиляции прикладных данных. Задача имеет ключевое значение для успешного применения современных технологий оптимистической репликации и создания перспективных распределенных приложений, таких как системы коллективной инженерии, мобильные базы данных, семантические сети. Рассматривается модельно-ориентированный подход к семантической реконсиляции данных, описываемых на языках объектно-ориентированного моделирования EXPRESS, UML/OCL, ODL/OQL. На основе статического анализа формальных спецификаций прикладной модели выявляются отношения зависимости и отношения порядка между операциями в конкурентных транзакциях и применяется аппарат логического, полисиллогистического вывода для выработки непротиворечивых (семантически корректных) и полных (обеспечивающих полноту результирующей транзакции) планов реконсиляции. Обсуждаются конкурентные преимущества предложенного модельно-ориентированного подхода, а также особенности его алгоритмической и программной реализации.

1. Введение Семантическая реконсиляция — фундаментальная научная и прикладная проблема, тесно связанная с применением современных технологий оптимистической репликации в распределенных системах и имеющая индустриально важные приложения, такие как системы коллективной инженерии (concurrent engineering environments), мобильные базы данных, распределенные сервисы, семантические сети [1]. Использование в подобных приложениях оптимистической репликации позволяет отказаться от необходимой централизации управления распределенными информационными ресурсами, свойственной пессимистическим моделям транзакций, и обеспечить возможность 1

Работа поддержана грантом Президиума РАН в рамках программы фундаментальных исследований “Математические и алгоритмические проблемы информационных систем нового поколения”. 141

эффективной одновременной работы пользователей и приложений с реплицированными версиями данных. Однако необходимость обнаружения и разрешения конфликтов в конкурентных транзакциях после их применения делают постановку задачи реконсиляции довольно нетривиальной. Требования корректности и полноты реконструируемой итоговой транзакции, а также условия семантической целостности результирующего представления данных существенно усложняют поиск допустимых решений. В настоящей работе обсуждается предложенный подход к семантической реконсиляции с использованием формальных спецификаций модели данных. Предполагается, что спецификации представлены декларативным образом на объектно-ориентированных языках EXPRESS [2], UML/OCL [3], ODL/OQL [4] (или на подобных им) и охватывают как структуры данных, так и заданные на них семантические ограничения. На основе формального анализа конкурентных транзакций выявляются возможные отношения между элементами данных и операциями, и применяется логический вывод для их семантически корректного и функционально содержательного слияния. При подобном подходе операции транзакций рассматриваются как объекты системы посылок и заключений, а отношения зависимости и порядка между ними — как правила логического вывода. Выбранная система отношений позволяет, с одной стороны, промоделировать сложные семантические зависимости между операциями транзакций, а с другой стороны — привлечь для решения рассматриваемой задачи хорошо развитый аппарат математической логики, в частности, методы полисиллогистического вывода [5] и интервальной темпоральной логики [6]. С целью обобщения рассматриваются бинарные и множественные отношения, а также учитываются возможные альтернативные способы задания отношений в аналитической и табличной форме. Обсуждаемый подход относится к так называемому смешанному классу методов и допускает конструктивную реализацию в составе распределенных систем с традиционными клиент-серверной и равнозначной P2P архитектурами на основе поддерживаемых протоколов транзакций. Он также реализуем в автономных приложениях, использующих файловый обмен данными, посредством непосредственного сравнения версий данных и реконструкции журналов изменений. Подход обладает рядом важных достоинств, связанных с гарантированным обеспечением целостности прикладных данных, которые определяются масштабными, семантически сложными моделями, при относительно невысоких вычислительных затратах. Возможности формализованного и содержательного применения подхода к широким классам приложений оптимистической репликации делают его привлекательным для реализации перспективных систем коллективной инженерии с долгими транзакциями и мобильных информационных систем с неустойчивым соединением и прерываемыми сессиями. 142

Раздел 2 посвящен обсуждению общих аспектов применения модельноориентированного подхода к построению прикладных интегрированных систем и необходимости ослабления фундаментальных принципов ACID (атомарности, целостности, изоляции и долговечности) для приложений оптимистической репликации. В разделе 3 описывается общая схема процесса семантической реконсиляции, а также на примере языка объектноориентированного моделирования EXPRESS приводится классификация типовых элементов данных и семантических ограничений. Проведение семантического анализа конкурентных транзакций на основе введенной классификации основных видов отношений зависимости и порядка между операциями обсуждается в разделе 4. Особое внимание уделяется установлению отношений на основе формального анализа семантических ограничений в прикладной модели данных. Процесс декомпозиции и редукции задачи с помощью определяемого графа и матрицы реконсиляции рассматривается в разделе 5. В разделе 6 приводятся конструктивные утверждения относительно корректности постановки задачи и поиска решений на основе эквивалентных преобразований матрицы реконсиляции. В заключении обсуждаются конкурентные преимущества предложенного модельно-ориентированного подхода, а также особенности его алгоритмической и программной реализации.

2. Роль модельно-ориентированного подхода Модельно-ориентированный подход становится важным доминирующим направлением в инженерии программного обеспечения, критичного по отношению к требованиям мобильности, интероперабельности, развертываемости в разнородных средах. Деятельность международных сообществ по разработке соответствующих информационных стандартов и многофакторных прикладных моделей, прежде всего, в рамках ISO 10303 (STEP — Standards for Representation and Exchange of Product Model Data) [7] и OMG MDA (инициатива Model-Driven Architecture группы индустриальных компаний Object Management Group) [8] способствует развитию этих тенденций. Вместе с тем, применение модельно-ориентированного подхода при построении прикладных интегрированных комплексов для проведения масштабных междисциплинарных проектов в науке и промышленности, обнаруживает ряд фундаментальных проблем. Прежде всего, это проблема синергетической организации работ с участием большого числа партнеров проекта, вовлеченных в единую творческую и производственную деятельность, но профессионально, организационно и географически отделенных друг от друга. Традиционные решения, использующие в качестве ключевых компонентов интеграции системы управления базами данных и системы документооборота, как правило, имеют довольно ограниченное применение. Они либо не обеспечивают целостность проектной информации, 143

либо существенно ограничивают возможности участников работать одновременно, что критично сказывается на качестве, стоимости и сроках проведения работ. Обеспечение эффективного мультидоступа к проектным данным при необходимой централизации управления ими и существенно распределенном, автономном и продолжительном характере проведения индивидуальных пользовательских сессий представляется в данном случае наиболее критичным. Предпринятые попытки ослабления базовых принципов ACID на основе идей последовательной целостности (serial consistency), использования версий данных (multiversion concurrency), применения специальных протоколов транзакций (transaction access patterns), а также разработки специальных механизмов альтруистических блокировок (altruistic locks) себя не оправдывают [9]. Вместе с тем, хорошо известны примеры успешного применения в ряде приложений оптимистической репликации. Это популярные распределенные сервисы UseNet; персональные помощники PDA (Personal Digital Assistants); мобильные базы данных, включая широко известную реализацию Bayou; системы совместной разработки программного обеспечения, в частности, CVS (Concurrent Versions System). Однако в применяемых в них методах игнорируются сложные семантические зависимости между данными и не обеспечивается желаемая целостность итогового представления. Например, реализуя типовые средства синтаксической реконсиляции текстовых документов, CVS не позволяет контролировать и, тем более, гарантировать семантическую корректность итоговых текстов программ на том или ином языке реализации. Однако, если в системах программной инженерии текстовые данные всегда могут быть скорректированы непосредственно программистами, в научных и промышленных приложениях, оперирующих со сложно структурированными моделями, их коррекция не может быть осуществлена усилиями пользователей. В связи с этим естественной выглядит попытка разработки и применения модельно-ориентированного подхода к семантической реконсиляции с использованием формальных спецификаций модели данных. Подобные спецификации предоставляют дополнительные возможности для статического и динамического анализа зависимостей между элементами данных и выработки непротиворечивых (семантически корректных) и полных (обеспечивающих полноту результирующей транзакции) планов реконсиляции. Исследования в этой области в настоящее время привлекают как коммерческие компании, так и многочисленные университетские коллективы.

3. Общий подход к реконсиляции В соответствии с главным принципом оптимистической репликации, приложения, выполняющиеся в распределенной среде, находятся либо на 144

этапе изолированного исполнения, либо на этапе реконсиляции. При изолированном выполнении приложение оперирует локальной репликой разделяемых данных, приводя их в некоторые новые состояния. Все выполняемые действия записываются в журналах транзакций, являющихся упорядоченными множествами локально применяемых операций. Все действия детерминированы и обратимы. Применение всех операций, занесенных в журнал, к начальной версии данных должно приводить к той же окончательной версии. И наоборот, применение обратных операций в противоположном порядке должно возвращать данные из конечного состояния в первоначальное состояние. Неважно, ведется ли журнал в приложении постоянно или реконструируется путем сравнения начальной и текущей версий данных. В этом отношении мы следуем смешанному классу методов (hybrid state-transfer and operation-transfer methods), охватывающему и анализ изменений в состоянии данных и контроль последовательностей выполнения операций в транзакциях. В ряде случаев, например, при определении и проверке предусловий для операций учет порядка их выполнения может быть исключен из анализа без потери содержательности результатов для приложения. Однако в дальнейшем мы будем рассматривать наиболее общий случай. Будем считать, что транзакции корректны в том смысле, что они могут быть корректно воспроизведены на основе журналов и гарантированно приводят к семантически целостному и функционально значимому представлению данных. Это важное допущение мотивируется тем, что используемые приложения, запущенные на локальной станции и обрабатывающие локальную реплику данных, работают правильно. В этом предположении, если начальное состояние данных было корректно, то корректная транзакция должна порождать итоговое состояние, удовлетворяющее всем семантическим ограничениям целостности и несущее необходимый функциональный смысл, определяемый пользователем. Одним из главных преимуществ обсуждаемого подхода является возможность сохранять свойства целостности при реконсиляции данных или, более точно, реконсиляции соответствующих журналов транзакций. Требование поддерживать семантическую целостность реплицированных данных рассматривается в нашем исследовании как базовый принцип функционально содержательной реконсиляции.

3.1. Этапы реконсиляции В предлагаемом подходе общий процесс реконсиляции включает в себя семь этапов, представленных на Рис. 1:

145

Расходящиеся реплики, информационная модель

СРАВНЕНИЕ Определение различий, гармонизация, построение журналов. СЕМАНТИЧЕСКИЙ АНАЛИЗ Анализ журналов, построение графа (матрицы) реконсиляции.

Граф (матрица) реконсиляции, перспективные решения, план реконсиляции

ДЕКОМПОЗИЦИЯ Поиск эквивалентностей, цепочек импликаций, редукция графа (матрицы). ПЛАНИРОВАНИЕ Поиск решений и построение плана реконсиляции.

ВАЛИДАЦИЯ Проверка решений по всем ограничениям. КОРРЕКЦИЯ Исправление нарушений, ослабление отношений.

Итоговая транзакция, согласованная реплика

ФУНКЦИОНАЛЬНЫЙ ОТБОР Выбор решения согласно пользовательским требованиям и политикам.

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

—

—

—

—

порядка (предшествования). Заметим, что проводимый на этой стадии семантический анализ охватывает как статические, так и динамические зависимости, которые могут быть реально проверены лишь с учетом текущего состояния элементов данных и фактических параметров операций транзакций. Поэтому мы считаем, что результаты, полученные на данном этапе, могут иметь различный уровень доверительности. Выявленные статические зависимости и отношения — абсолютно достоверны (необходимы и достаточны для корректности результирующей транзакции), динамические зависимости и отношения — предположительно достоверны (достаточны, но вовсе не необходимы для корректности транзакции) и поэтому в ряде случаев могут быть проигнорированы и уточнены на более поздних этапах валидации и коррекции. Декомпозиция и редукция: На основе анализа отношений определяются классы эквивалентности, импликативные цепочки и свободные группы операций. Для сформированных групп операций переустанавливаются отношения зависимости с другими операциями и группами. Целью данного этапа является уменьшение количества логических элементов (переменных и отношений) при логическом анализе транзакций и предотвращение комбинаторных проблем, обычно возникающих на последующих этапах. Планирование: Строятся возможные варианты результирующей транзакции, которые удовлетворяли бы всем выявленным отношениям зависимости и порядка и тем самым гарантировали бы ее корректность. Во внимание принимается также требование наиболее полного покрытия результирующей транзакцией множеств операций в исходных транзакциях, поскольку именно этим определяется ее функциональная содержательность. В случаях, когда число приемлемых вариантов слишком велико, может быть построен план реконсиляции, который бы учитывал возникшие конфликты и определял альтернативные способы их разрешения, например, на основе дерева принятия решений. Валидация: Если в сопутствующем анализе игнорировалась часть ранее установленных (предположительно достоверных) отношений, они должны быть перепроверены с учетом фактического текущего состояния данных и значения параметров операций, поскольку только в этом случае можно гарантировать корректность итоговой транзакции. В случае обнаружения нарушений анализируемые варианты транзакций отвергаются, а ранее построенные планы реконсиляции уточняются путем исключения заведомо неприемлемых решений. Коррекция: Если содержательные решения не былы найдены (например, были найдены лишь тривиальные решения, состоящие в принятии всех операций первой или второй транзакции), то конструктивным подходом может оказаться ослабление предположительно достоверных отношений 147

между операциями и пересмотр результатов семантического анализа. Если на этапе валидации были выявлены нарушения, но все-таки желательно представить критичные операции в результирующей транзакции; могут быть применены корректирующие методы, вносящие необходимые исправления и переводящие транзакцию и данные в корректное состояние. В обоих случаях процесс возвращается к более ранним этапам реконсиляции; — Функциональный отбор: Наконец, решения, прошедшие этап валидации, ранжируются и отбираются пользователем согласно функциональным требованиям, предъявляемым к результатам реконсиляции. При наличии плана пользователь последовательно уточняет детали итоговой транзакции, включая в ее состав требуемые операции. С целью автоматизации подобных действий могут быть определены и применены политики исключения и консолидации, основанные на априорно заданных функциональных критериях и приоритетах. В настоящей статье мы сосредоточимся на втором, третьем и четвертом этапах, охватывающих семантический анализ транзакций с использованием формальных спецификаций прикладной информационной модели, а также методы логического, прежде всего, полисиллогистического вывода для поиска решений рассматриваемой постановки задачи реконсиляции. Методы семантической декомпозиции транзакций более подробно обсуждаются в нашей работе [10].

3.2. Действия Действие — это базовая операция, выполняемая приложением над реплицированными данными. Оно хранится в журнале и становится доступным для анализа сразу после записи или реконструкции журнала. Мы будем рассматривать действие как структуру, состоящую из шести элементов: — целевой объект, идентифицирующий элемент (или элементы) данных, на которое направлено действие; если язык информационного моделирования допускает конструкции запросов, то целевой объект также может быть выражен в терминах запросов; — статус, определяющий метод для динамической проверки, применено ли уже действие или нет; методы статуса не имеют побочных эффектов и возвращают логическое значение; — предусловие, определяющее аналогичный метод для проверки, можно ли выполнить данное действие при текущем состоянии данных; — операция — метод доступа или модификации элемента (элементов) данных, определяемого целевым объектом; предполагается, что операция не оказывает побочного эффекта на данные, не определенные явно как объект действия, но может нарушить их семантическую корректность в контексте наложенных ограничений и вносимых сторонних изменений; 148

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

3.3. Типы данных и виды ограничений Объектно-ориентированные языки моделирования, такие как EXPRESS, UML/OCL, ODL/OQL, предоставляют широкий спектр декларативных и императивных конструкций для описания структур данных и накладываемых на них семантических ограничений. В частности, в языке EXPRESS определяются простые типы данных с общепринятой семантикой: вещественный, целый, числовой, булевский, логический, строковый, двоичный строковый. Сложные типы охватывают четыре вида коллекций: списки, множества, массивы, мультимножества, а также перечисления, выборки и переопределяемые типы, уточняющие 149

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

SIMPLE

CONSTRUCTED

ENUMERATION

STRING

AGGREGATE

NAMED

SELECT

DEFINED

LOGICAL

NUMBER

BINARY

BOOLEAN

REAL

SET OF GENERIC

INTEGER

SET

ENTITY

BAG OF GENERIC

LIST OF GENERIC

ARRAY OF GENERIC

BAG

LIST

ARRAY

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

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

WIDTH OF STRINGS, BINARIES SIZE OF AGGREGATES UNIQUENESS OF ELEMENTS IN SETS MANDATORY ELEMENTS IN DENSE ARRAYS VALUE DOMAIN CONSTRAINT

CONSTRAINT

LOCAL RULE

ATTRIBUTE TYPE COMPATIBILITY MANDATORY ATTRIBUTES CARDINALITY OF INVERSE ASSOCIATIONS UNIQUENESS OF ATTRIBUTE VALUES OBJECT DOMAIN CONSTRAINT

GLOBAL RULE

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

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

4.1. Понятие корректной транзакции Пусть X – область значений, которые могут принимать данные рассматриваемой прикладной объектно-ориентированной модели, C(x) ≡ {ci(x) | i =1,..,I} – система ограничений, наложенных моделью на состояние x  X и принимающих логическое значение true, если ограничение удовлетворено, и false, если оно нарушено. Если все ограничения удовлетворены в точке x  X, тогда мы говорим, что x находится в корректном состоянии, или C(x) = true. Если хотя бы одно из условий не выполняется, т.е. ci(x) = false, то состояние x  X считается некорректным, что выражается соответствующим образом: C(x) ≡ c1(x)  c2(x) … cI(x) = false. Для некоторых ограничений ci (x) могут быть определены корректирующие методы rij  R таким образом, что если ci (x) = false, то применение метода приводит данные в состояние, удовлетворяющее ранее нарушенному ограничению, т.е. x' = rij(x), ci (x') = true. Мы считаем, что для любого ограничения ci (x), i = 1,…I могут быть определены соответствующие корректирующие методы rij  R. Однако они должны применяться с учетом всех наложенных ограничений ci' (x), i'  i, i' = 1,…I и возможного нарушения некоторых их них, если они уже были удовлетворены. Если данные находятся в состоянии x  X, то выполнение действия t(xt, pt) с параметрами pt над целевым объектом xt = PrDt x, являющимся некоторой проекцией x на область определения операции Dt, приведет к переводу целевого объекта в состояние x't  X, а всех данных – в состояние x'  X. Мы будем обозначать это следующим образом: x't = t(xt) и x' = t(x). Отдельно выполненное действие может нарушать целостность данных, т.е. если C(x) = true, то C(x'), где x' = t(x), не обязательно принимает значение true. Но мы требуем, чтобы любая корректная транзакция вида T = { tk (xt, pt) | k = 1,…,K } сохраняла целостность данных. Если транзакция T корректна и начальное состояние данных корректно (C(x) = true), то C(x') = true, x' = T(x). При этом не требуется, чтобы каждое действие tk  T или некоторые группы действий tk1, tk2,…, tkn  T перманентно сохраняли целостность данных во время выполнения транзакции. Для применения каждое действие корректной транзакции должно удовлетворять соответствующему предусловию. Поскольку действия в транзакциях не подчиняются коммутативным свойствам, порядок их применения существенен как для выполнения предусловий, так и для конечных результатов. Поэтому вводимое понятие корректной транзакции предполагает выполнимость всех определенных предусловий для действий и учитывает порядок их следования. В дальнейшем рассматриваются только корректные транзакции за исключением, естественно, некоторых временных представлений журналов. Теперь определим возможные виды отношений между операциями. Временный журнал транзакции T = T'  T'' – это упорядоченное множество 152

действий, полученное путем объединения журналов реконсилируемых транзакций T' и T'', причем если x – начальное состояние данных и x' и x'' – расходящиеся реплики, то x' = T'(x) и x'' = T''(x).

4.2. Отношения зависимости и порядка Отношения зависимости между операциями D определяются логическими операторами отрицания и импликации следующим образом. Для операций t1, t2  T, если t1 → t2, то журнал должен содержать t2 при условии, что он содержит t1. Если ¬t1 → ¬t2, то в журнале должна отсутствовать операция t2, если в нем отсутствует операция t1. Эти отношения несимметричны, рефлексивны и транзитивны. Для операций t1, t2  T, если t1 → ¬t2, то в журнале не может присутствовать t2, если он содержит t1. Если ¬t1 → t2, то журнал должен содержать t2, если в него не входит t1. Эти отношения симметричны, не рефлексивны и не транзитивны. Эти четыре логические отношения с характеристическими функциями, приведенными в Таблице 1, рассматриваются как основные отношения зависимости. Также мы считаем полезным использование симметричных отношений эквивалентности t1 ~ t2 ≡ t1 → t2  t2 → t1 и взаимоисключения t1  t2 ≡ t1 → ¬t2  ¬t1 → t2. Отношение эквивалентности устанавливается между двумя операциями t1, t2  T и означает, что эти операции могут встречаться в транзакции T только совместно. Отношение взаимоисключения между t1, t2  T обязывает транзакцию T включать в себя либо t1, либо t2 и запрещает содержать обе эти операции или ни одну из них. t1 0 0 1 1

t2 0 1 0 1

t1 → t2 1 1 0 1

¬

t1 → t2 1 1 1 0

¬

t1 → t2 0 1 1 1

t1 ~ t2 1 0 0 1

t1  t2 0 1 1 0

Таблица 1. Характеристические функции бинарных отношений зависимости. В некоторых случаях приходится рассматривать более сложные множественные отношения между операциями. В общем виде они представляются характеристической функцией D(t1, t2, t3, …) и соответствующей таблицей значений, подобной Таблице 1. В качестве примера рассмотрим множественное отношение кардинальности D(n:m)(t1+,…, t+I+ , t1–,…, t–I–). Данное отношение связано с ограничениями кардинальности ассоциаций и размерности коллекций элементов данных в объектно-ориентированной модели. Оно считается выполненным, если n ≤ card( T+ ) – card( T– ) ≤ m, где T+ = { ti+, i  (1, I+) | ti+ = true }, T– = { ti–, i  (1, I–) | ti– = true }, 153

а функция card() возвращает мощность соответствующих подмножеств операций T+ и T–. Характеристические функции отношений кардинальности D(0:0)(t1+, t2+, t1–, t2–), D(1:1)(t1+, t2+, t1–, t2–) и D(2:2)(t1+, t2+, t1–, t2–) приведены в Таблице 2. Функции других возможных отношений могут быть выражены через представленные функции с помощью следующих очевидных тождеств: D(n:m)(t1+,…, t1–,…) ≡ D(-m:-n)(t1–,…, t1+,…), D(n:m)(t1+,…, t1–,…) ≡ D(n:n)(t1+,…, t1–,…) D(n+1:n+1)(t1+,…, t1–,…)… D(m:m)(t1+,…, t1–, …). t1+ T t2+ T t1– T t2– T

0 0 0 0

0 0 0 1

0 0 1 0

0 0 1 1

0 1 0 0

0 1 0 1

0 1 1 0

0 1 1 1

1 0 0 0

1 0 0 1

1 0 1 0

1 0 1 1

1 1 0 0

1 1 0 1

1 1 1 0

1 1 1 1

D(0:0) (t1 ,t2+,t1–,t2–) D(1:1) + + – – (t1 ,t2 ,t1 ,t2 ) D(2:2) + + – – (t1 ,t2 ,t1 ,t2 )

1

0

0

0

0

1

1

0

0

1

1

0

0

0

0

0

0

0

0

0

1

0

0

0

1

0

0

0

0

1

1

0

0

0

0

0

0

0

0

0

0

0

0

0

1

0

0

0

+

Таблица 2. Характеристические функции множественных отношений кардинальности. Часто требуется удовлетворить некоторое ограничение c = с(x1, x2, …), выраженное алгебраическим образом с помощью соответствующей логической функции нескольких переменных. Если конкурентные транзакции содержат операции модификации элементов данных, являющихся фактическими параметрами функции ограничения, то возможным способом сохранить целостность является принятие всех операций модификации первой транзакции или всех операций модификации второй транзакции. В этом случае между операциями устанавливается отношение алгебраической зависимости Dc (t1', t2', …,t1'', t2'',…), где операции первой транзакции t1', t2' T' и операции второй транзакции t1'', t2'' T' модифицируют элементы данных, на которые наложено ограничение c(x1, x2,…). Будучи выполненным, данное отношение приводит к выделению классов эквивалентности для операций каждой транзакции и исключению ситуаций одновременного их применения в результирующей транзакции: D c (t1', t2',…,t1'', t2'',…) ≡ t1'  t1''  t1' ~ t2'  t2' ~ t3' … t1'' ~ t2''  t2'' ~ t3'' … Отношение порядка или предшествования операций в транзакции P определим следующим образом. Для операций t1, t2  T, если t1  t2, то 154

операция t1 должна появиться до операции t2 (не обязательно непосредственно перед ней) в любом решении, которое одновременно содержит операции t1 и t2. Отношение порядка несимметрично, не рефлексивно, но транзитивно. Так как отношение подразумевает наличие обеих операций в одной транзакции, отношение t1  t2 может быть установлено только между теми операциями, которые не связаны отношениями зависимости t1 → ¬t2 и t1  t2 непосредственно или косвенно через другие отношения. Обсуждаемые отношения являются строгими в том смысле, что если операции не удовлетворяют некоторым установленным отношениям, то транзакция необходимо становится некорректной, что означает невозможность ее выполнения или потерю целостности воспроизводимыми данными. В ряде случаев могут быть рассмотрены более слабые отношения, обозначаемые D и P, которые совпадают со строгими отношениями D, P за исключением того, что они имеют достаточный, но не необходимый характер для корректности транзакции. Другими словами, иногда они могут быть не выполнены, не нарушая условия корректности транзакции и целостности данных. Поскольку риск нарушения все равно остается, предварительные решения (транзакции и данные), полученные без учета подобных отношений, должны быть дополнительно проверены на более поздних этапах рассмотренного выше процесса реконсиляции.

его атрибутов, поэтому t1'  t2'. Для операций второй транзакции должно быть установлено отношение эквивалентности t2'' ~ t1'', так как установка значения атрибута c1.ref обязательна и операции могут быть включены в итоговую транзакцию только совместно при отношении предшествования t1''  t2''. ENTITY A; x : REAL; y : REAL; z : REAL; q : SET [3:3] OF STRING; id : INTEGER; UNIQUE Ur1: id; WHERE Wr1 : (x + y + z < 1); Wr2 : (x + y < 1) AND (z < 1); END_ENTITY; ENTITY B; ref : OPTIONAL A; END_ENTITY; ENTITY C; ref : A; END_ENTITY;

4.3. Примеры формального анализа транзакций Обратимся к следующей демонстрационной модели, формально описанной на языке EXPRESS (см. Рис. 4). Модель описывает объектный тип данных A с вещественными атрибутами x, y, z, целочисленным идентификатором id и квалификационным именем q, представленным множеством из трех строк. Модель определяет также объектные типы данных B и C, содержащие необязательную и обязательную ссылки соответственно на экземпляр объекта типа A. Определение типа A содержит правила Wr1, Wr2, ограничивающие допустимую область значений атрибутов x, y, z, а также правило уникальности Ur1 для значений атрибута id, действие которого распространяется на всю популяцию объектов типа A. Пусть начальное состояние данных x = {a  A, b  B, b.ref = a,…} и сформирован временный журнал совмещенной транзакции T'  T'' = {t1' = new(b1B), t2' = wr(b1.ref, a), t1'' = new(c1C), t2'' = wr(c1.ref, a), …}, где символы new, wr, del обозначают операции создания объекта, модификации его атрибутов и удаления соответственно. В дальнейшем используются также символы in, rm, обозначающие операции добавления элементов в атрибуты типа коллекций и их исключения из подобных атрибутов. Тогда между операциями должны быть установлены следующие отношения. Импликация t2' → t1' вытекает из того, что атрибут b1.ref может быть установлен, если только объект b1 существует. Сам же объект должен быть создан перед установкой 155

Рис. 4. Демонстрационная модель данных, формально описанная на языке EXPRESS Аналогичные отношения t1' → t2', t1'  t2'', t1'  t2', и t1''  t2'' могут быть установлены для операций в сформированном временном журнале T'  T'' = {t1' = del(a), t2' = wr(b1.ref, 0), t1'' = new(b1B), t2'' = wr(b1.ref, a), …}. Отношение t1' → t2' вытекает из того, что удаление объекта a требует обнуления соответствующей ссылки b1.ref, указывающей на него. Отношение t1'  t2'' появляется, потому что операции удаления объекта a в первой транзакции и установки на него ссылки b1.ref во второй транзакции являются взаимоисключающими. Для временного журнала T'  T'' = {t1' = rm(a.q,…), t2' = in(a.q,…), t1'' = '' rm(a.q,…), t2 = in(a.q,…) …}, чтобы сохранить атрибут q в корректном состоянии, необходимо потребовать, чтобы количество элементов соответствующего множества было ровно 3. Предполагая, что начальное состояние было корректным и применение каждой транзакции не нарушает целостности, мы устанавливаем отношение кардинальности D(0:0)(t2'+, t2''+, t1'–, t1''–). Это означает, что количество добавляемых элементов равно количеству исключаемых элементов, и мощность множества остается неизменной. 156

Рассмотрим отношения между операциями, порождаемые правилами ограничения области значений. Для корректности итоговой транзакции с временным журналом T'  T'' = {t1' = wr(a.x), t2' = wr(a.y), t1'' = wr(a.z), …} требуется выполнение отношения алгебраической зависимости DWr1(t1', t2', t1''). В этом случае в итоговую транзакцию включаются все участвующие в ограничении операции первой или второй транзакции, и ограничение будет гарантированно удовлетворено. Отметим, что данное отношение носит предположительный характер, являясь достаточным, но не необходимым условием корректности транзакции. Поэтому при необходимости оно может быть снято на этапе семантического анализа транзакции, но тогда связанное с ней ограничение обязано быть проверено на последующем этапе валидации. Аналогичный вывод справедлив для отношения DWr2(t1', t2', t1''). Однако более детальный анализ показывает, что данное отношение следует исключить из рассмотрения, так как модифицируемые в различных транзакциях атрибуты появляются в различных термах конъюктивной нормальной формы предиката ограничения области значений. Наконец, рассмотрим отношения, устанавливаемые для ограничения уникальности. Предположим, что в каждой транзакции создается объект типа A, и инициализируется его обязательный атрибут id. Журнал для представления транзакции выглядит следующим образом: T'  T'' = {t1' = new(a1A), t2' = wr(a1.id, id1), t1'' = new(a2A), t2'' = wr(a2.id, id2),…}. Чтобы удовлетворить ограничение уникальности значений атрибута id, в дополнение к отношениям импликации t2' → t1', t2'' → t1'' и предшествования t1'  t2', t1''  t2'' следует установить отношение исключения t1'  t2''. Однако такое отношение может оказаться слишком сильным, так как присваиваемые значения идентификаторов могут различаться. Поэтому здесь следует применить нестрогую форму отношения. Заметим, что даже если в дальнейшем на этапе валидации будет обнаружено, что идентификаторы случайно совпали, существует возможность переназначить их с использованием корректирующих методов. Конечно, приведенные примеры не исчерпывают все содержательные случаи семантического анализа транзакций. Тем не менее, они описывают типовые ситуации, возникающие на данном этапе реконсиляции, и иллюстрируют возможности применения формального, основанного на спецификациях прикладной модели данных, подхода. Отметим только, что для определения алгебраических зависимостей между данными и установления соответствующих отношений между операциями транзакций могут быть использованы методы инкрементального анализа и верификации данных [11, 12].

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

5. Логический анализ

Граф реконсиляции обладает рядом свойств, существенных для его конструктивного анализа. Так как предполагается, что каждая транзакция, участвующая в процессе реконсиляции, является корректной, ребра, соответствующие обратным импликациям t1 → ¬t2 и ¬t1 → t2, могут быть

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

5.1. Граф реконсиляции Граф (гиперграф) реконсиляции RG определим как набор пяти множеств (V = V1  V2  VC , E = ED EP), где — V1, V2 – множества вершин, соответствующих операциям исходных транзакций T’ и T”. VC – множество операций, применяемых в корректирующей транзакции. При проведении анализа каждой вершине на графе присваивается логический статус. Статус указывает, включается ли соответствующая операция в итоговый журнал или нет. — ED, EP – множества ребер (гипер-ребер), которые соответствуют отношениям зависимости и порядка, установленным между операциями. Каждое ребро помечается семантическим ограничением, порождающим соответствующее отношение. Бинарные отношения графически представляются обычными линиями, а множественные отношения — прямоугольными элементами, опирающимися на узловые вершины.

158

установлены только между вершинами, принадлежащим разным транзакциям. В то же время ребра, соответствующие прямым импликациям t1 → t2 и ¬t1 → ¬ t2, могут появиться как внутри отдельных транзакций, так и в разных транзакциях. Аналогично, между парой вершин одной транзакции не может существовать противоположных отношений порядка, что противоречило бы возможности их одновременного применения. Следующие свойства связаны с обобщающими идеями сильных цепей зависимости и предшествования. Пусть RG(V,E) — граф реконсиляции. Путь v1(t1), v2(t2), ..., vn(tn)  V вдоль ребер зависимости e1(D1), e2(D2), …, en-1(Dn-1)  ED, начинающийся в вершине v1(t1) и заканчивающийся в вершине vn(tn), назовем цепью зависимости (или vn зависит от v1), если только существует соответствующая последовательность отношений зависимости t1D1t2, t2D2t3, …, tn-1Dn-1tn, эквивалентная простой импликации t1Dtn. Прямой зависимостью назовем цепь зависимости, эквивалентную импликации t1 → tn или ¬t1 → ¬tn. Обратной зависимостью будем называть цепь, эквивалентную импликации t1 → ¬tn или ¬t1 → tn. В графе реконсиляции не существует циклов обратной зависимости. Если бы такой цикл был найден, это означало бы, что любой статус операции, приписанный ее вершине, не соответствует логическим отношениям. Это противоречит существованию тривиальных решений логической системы, в качестве которых всегда могут быть выбраны операции первой или второй транзакции.

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

Операции (V1, V2, Vc)

wr(a.x) –

Отношения предшествования (EP)

Путь v1(t1), v2(t2), ..., vn(tn)  V на графе реконсиляции RG(V,E) вдоль ребер предшествования e1(P1), e2(P2), …, en(Pn-1)  EP, начинающийся в вершине v1(t1) и заканчивающийся в вершине vn(tn), назовем цепью предшествования (или v1 предшествует vn), если только отношения предшествования P1, P2, …, Pn-1 устанавливают порядок t1  t2, t2  t3, …, tn-1  tn. В графе реконсиляции не существует циклов предшествования, содержащих только вершины какой-либо одной транзакции. В противном случае это также противоречило бы существованию тривиальных решений задачи.

159

t1  t2 –

v1(t1)

v2(t2)

t1  t2 –

v1(t1)

v2(t2)

Отношения зависимости (ED) ¬

t1  t2 –

v1( t1)

v2( t2)

t1  t2 – t1  ¬t2 –

v1( t1)

v2( t2)

v1( t1)

v2( t2)

v1( t1)

v2( t2)

v1( t1)

v2( t2)

¬

¬

¬

t1  t2 – t1  t2 –

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

wr(a.x)

Рис. 5. Графическая нотация элементов графа реконсиляции. Опишем предлагаемый метод логического вывода, используя представленную графическую нотацию. Для выделения цепей зависимости и определения того, какие вершины могут зависеть от заданной вершины, удобно использовать следующее визуальное правило. Заметим, что цепями зависимости в графе реконсиляции являются только те цепи, ребра которых инцидентны общим вершинам с чередующимися цветами кружков. Это объясняется тем, что пара цветов, присваиваемая отношению импликации, соответствует запрещенной комбинации статусов операций, при этом черный цвет обозначает статус 160

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

Vc

new(a1A)

V2 new(a2A)

wr(a1.guid,id1) wr(a2.guid,id2) new(b1B)

wr(a1.guid,id3) wr(a1.x,0)

wr(a1.y,1.0)

wr(a1.z,2.0) del(a3A)

wr(b1.ref,a2)

wr(c.ref,a3)

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

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

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

Значительная универсальность, достигнутая за счет применения общего математического аппарата, не препятствует содержательному применению подхода к разнообразным классам приложений, включая системы коллективной инженерии с долгими транзакциями и мобильные информационные системы с прерываемыми сессиями. Благодаря использованию формальных методов статического анализа спецификаций прикладных моделей, удается преодолеть проблемы комбинаторного характера, свойственные многим другим методам. Важно отметить, что логический вывод является одним из наиболее затратных элементов предлагаемого подхода, поскольку число операций в конкурентных транзакциях и число установленных отношений между ними может быть значительно. Тем не менее, применение разреженных схем представления логических отношений и соответствующих матричных методов преодолевает эту проблему. Данный аспект является принципиально важным, поскольку позволяет существенно снизить вычислительную сложность и сделать возможным практическое применение подхода для важных научных и индустриальных приложений. Литература [1] Y. Saito, M. Shapiro. Optimistic Replication // In ACM Computing Surveys, Vol. 37, No. 1, March 2005, pp. 42–81. [2] ISO 10303-11: 1994, Industrial automation systems and integration — Product data representation and exchange — Part 11: Description methods: The EXPRESS language reference manual. [3] Unified Modeling Language (UML), Version 2.0, http://www.uml.org/#UML2.0. [4] The Object Data Standard: ODMG 3.0. eds. R.G.G. Cattel, D.K. Barry. Morgan Kauffmann, 2000. [5] А.Д. Закревский. Логика распознавания. — Мн.: Наука и техника, 1988.— 118 с. [6] J.F. Allen, G. Ferguson. Actions and Events In Interval Temporal Logic. // In Technical report 521, University of Rochester, Computer Science Department, July 1994, pp.1–59. [7] ISO 10303: 1994, Industrial automation systems and integration — Product data representation and exchange. [8] OMG. Model Driven Architecture: How systems will be built, http://www.omg.org/mda. [9] K. Ramamritham, P. Chrysanthis. Executive Briefing: Advances in Concurrency Control and Transaction Processing. IEEE Computer Society Press, 1997. [10] Semenov V.A., Karaulov A.A., Semantic-Based Decomposition of Long-Lived Transactions in Advanced Collaborative Environments. // Proceedings of 6 European Conference on product and process modeling, ECPPM 2006, Valencia, September 11– 15, 2006, ISBN 10: 0-415-41622-1, pp.223–232. [11] Семенов В.А., Морозов С.В., Тарлапан О.А. Инкрементальная верификация объектно-ориентированных данных на основе спецификации ограничений. // Труды ИСП РАН, 2004, стр. 23-55. [12] Semenov V.A., Bazhan A.A., Morozov S.V., Tarlapan O.A. Efficient Verification of Product Model Data: an Approach and an Analysis. // Proceedings of 22nd Conference on Information Technology in Construction, CIB-W78, Dresden, July 19-21, 2005, ISBN:3-86005-478-3, pp. 261-268.

163

Разработка ОС реального времени для цифрового сигнального процессора В. В. Рубанов, К. А. Власов Аннотация. В статье рассматривается задача построения операционной системы реального времени (ОСРВ) для цифрового сигнального процессора. Описывается конкретная реализация ОСРВ MicroDSP-RTOS, разработанная в ИСП РАН. Рассматривается архитектура ОС и предоставляемые функции. Кроме того, описываются доработки в инструментарии кросс-разработки MetaDSP для обеспечения эффективной разработки и отладки многозадачных приложений под платформу MicroDSP-RTOS.

1. Введение В настоящее время всё большую роль начинают играть встраиваемые системы на основе цифровых процессоров обработки сигналов (ЦПОС). ЦПОС используются практически во всех областях деятельности человека — в быту, науке, медицине. Важнейшим программным компонентом, лежащим в основе функционирования таких систем, является операционная система, которая позволяет запускать одновременно несколько разных программ и организовывать взаимодействие между ними для решения одной общей задачи. Для встраиваемых систем обработки сигналов характерны операционные системы реального времени (ОСРВ). Эти системы применяются в тех случаях, когда главная задача — успеть среагировать на событие в рамках строго определенного максимального времени реакции. Например, это может быть сигнал на датчике, отображающем текущее состояние какого-то объекта в реальном времени. Возможна ситуация, когда состояние объекта на короткое время меняется, а потом возвращается обратно, и если это изменение останется незамеченным и необработанным системой, последствия могут быть самыми разными — от совершенно безобидных до катастрофических. Важно также отметить, что возможность «успеть среагировать на событие» вовсе не означает высокую скорость работы. Система может работать относительно медленно, и всё же являться системой реального времени. Главное отличие ОСРВ от ОС общего назначения — это некий фиксированный промежуток времени, в течение которого система гарантированно среагирует на событие и выполнит его обработку. Величина 165

этого промежутка времени определяется решаемой задачей и является одним из требований к разрабатываемой системе. Он может быть очень коротким, но может быть и длинным, важно лишь то, что он фиксирован и известен заранее. Применение систем реального времени может быть самым разнообразным. Рассмотрим, например, работу сотового телефона. Его процессор должен выполнять одновременно довольно много задач: приём и кодирование речи при разговоре, отправку закодированного звука на ретрансляционную станцию, приём входящего закодированного звукового потока, раскодирование и воспроизведение его; плюс к этому необходимо обмениваться со станцией всякого рода служебной информацией — такой как переход из зоны в зону и переключение на другую станцию, отслеживание уровня сигнала, при необходимости — усиление его и так далее. Причём многие из этих задач должны выполняться в реальном времени, без задержек. Например, задержка в обработке сигнала с микрофона приведёт к тому, что часть фразы будет утеряна; запаздывание с переключением на другую ретрансляционную станцию может привести к потере связи и разрыву соединения. Таким образом, применение операционной системы реального времени в данной ситуации не только оправдано, но и необходимо. В данной статье мы рассмотрим операционную систему реального времени, разработанную в ИСП РАН для частной «системы на чипе» (System-On-Chip) на базе цифрового сигнального процессора MicroDSP 1.1, когда на одном общем кристалле размещаются сам процессор, модули расширения, программная память и два банка памяти данных. Размещение их на одном кристалле позволяет обеспечить очень быстрый доступ к ячейкам памяти (обращение к памяти занимает один такт). Размер банков памяти данных может меняться от 0 до 65536 16-битных слов; они независимы, и к ним можно обращаться одновременно. Программная память может составлять до 256К слов (4 страницы по 64К слова), размер слова составляет 24 бита (длина инструкций процессора). Стек организуется программно, при помощи трёх специальных регистров, содержащих границы стека и текущее положение указателя стека. Процессор поддерживает до 15 программируемых прерываний с индивидуальной настройкой приоритетов и маскированием, а также доступны три таймера. Предполагалось, что система будет работать одновременно не более, чем с 64 задачами. Каждая задача имеет свой статический приоритет, причём двух задач с одинаковыми приоритетами быть не может. Планировщик задач выбирает для запуска задачу с наивысшим приоритетом из тех, что находятся в состоянии готовности (то есть, в принципе, допустима ситуация, когда какая-то задача ни разу не получит управления). Процессорное время выделяется задачам квантами, длительность кванта может варьироваться. Увеличение длительности кванта ухудшает параллелизм, но снижает затраты, связанные с переключением процессов; уменьшение длительности, соответственно, – наоборот. Для каждой задачи оптимальное значение 166

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

2. ОСРВ MicroDSP-RTOS Операционная система MicroDSP-RTOS предназначена для работы с многозадачными приложениями. Под задачей мы в данной статье подразумеваем составную часть какого-либо сложного приложения, работающую самостоятельно и практически независимо от остальных частей. Также задачи часто называют процессами или потоками. Операционная система производит необходимые действия по распределению процессорного времени между задачами и обеспечивает переключение между ними, сохраняя и восстанавливая контексты так, что переключение остаётся для задач совершенно прозрачным. Также система содержит набор функций для выполнения различных служебных действий (функции ядра ОС), таких как инициализация внутренних структур, запуск самой ОС (по сути — запуск аппаратного таймера), механизм сохранения/восстановления контекста и переключения задач и так далее. Что касается предоставляемого системой API, здесь присутствуют функции для управления самими задачами, их состоянием, функции для синхронизации и взаимодействия задач между собой, для управления динамической памятью. Рассмотрим возможности системы более подробно.

2.1. Общая функциональность Всего в системе может присутствовать максимум 63 пользовательских задачи. Сами задачи являются обычными функциями без параметров, чаще всего представляющими собой бесконечный цикл. Каждой задаче соответствует приоритет от 0 до 62, задаваемый при подключении, причём не может существовать двух задач с одинаковыми приоритетами. Системное время квантуется, и в каждый квант времени выполняется задача, имеющая наивысший приоритет (самый высокий приоритет соответствует значению 0) среди тех, которые не находятся в состоянии ожидания. На приведённой ниже схеме (Рис. 1) можно видеть основные состояния, в которых может находиться задача, и возможные переходы между состояниями.

167

Рис.1. Схема переключения состояний задач После истечения каждого кванта времени (system tick) вызывается функция обработки прерывания таймера. Эта функция выполняет следующие действия:  обновляет значение времени ожидания (таймаута) для каждой задачи, находящейся в состоянии ожидания по какой-либо причине;  если у какой-то из задач таймаут истёк, переводит эту задачу в состояние готовности (Ready);  после этого из всех задач, находящихся в состоянии готовности, выбирает задачу с наивысшим приоритетом и переключается на неё (сохранив контекст текущей задачи, если это требуется). В системе всегда присутствует одна внутренняя задача, называющаяся background и имеющая самый низкий возможный приоритет — 63. Это значение ниже приоритета любой из пользовательских задач, и поэтому эта задача выполняется только тогда, когда все пользовательские задачи находятся в состоянии ожидания; таким образом, задача background является индикатором простоя системы. В начальной реализации эта задача представляла собой цикл, состоящий из нескольких инструкций NOP. В дальнейшем туда была добавлена инструкция IDLE, которая останавливает процессор до тех пор, пока не появится запрос на прерывание. Тем самым было снижено энергопотребление процессора на время простоя.

2.2. Управление задачами 1. Подключение задачи. Задачи подключаются динамически, поэтому в начале нужно явно вызвать функцию подключения для каждой задачи, которая будет выполняться. 168

2.

3.

4.

5.

6.

7.

8.

При подключении задача добавляется во внутренние структуры данных системы, стек инициализируется стартовым контекстом, который будет восстановлен при первом переключении на эту задачу. Отключение задачи. Эта функция полностью удаляет задачу из всех внутренних структур данных операционной системы, и дальнейшая работа с этой задачей становится невозможной. Для повторного использования задачи её требуется снова подключить, после чего выполнение задачи пойдёт с самого начала. Приостановка выполнения задачи. Выполнение задачи может быть на время приостановлено. Это может потребоваться, например, чтобы запустить выполнение менее приоритетной задачи, имея более приоритетную активную задачу. При вызове функции указывается длительность задержки в квантах времени. По истечении этого времени задача переводится в состояние готовности и, если она является наиболее приоритетной, получает управление. Восстановление из приостановленного состояния. Эта функция позволяет при необходимости досрочно поставить приостановленную задачу в очередь на выполнение, переведя её в состояние готовности. Блокировка задачи. Блокировка задачи очень похожа на отключение. Единственное отличие состоит в том, что при блокировке состояние задачи полностью запоминается и может быть восстановлено путем вызова соответствующей функции, после чего задача продолжит выполнение с того же места, где была остановлена. В случае же отключения продолжить выполнение задачи нельзя, её можно только подключить заново, и она начнёт выполняться с самого начала. Вывод из режима блокировки. Эта функция выполняет действие, обратное блокированию. Состояние задачи восстанавливается в то, которое было до блокировки, за одним только исключением: если задача выполнялась, она переводится в состояние готовности, а не выполнения. Таймаут (для состояний приостановки и ожидания) начинает уменьшаться с каждым квантом времени; задача может получать сигналы и сообщения и так далее. Получение данных, переданных задаче. При подключении задачи ей можно передать какие-либо данные (один из параметров функции подключения — адрес произвольной структуры данных). Данная функция позволяет получить этот адрес, чтобы иметь возможность обратиться к переданным данным. Изменение приоритета задачи. Данная функция позволяет изменить приоритет любой задачи (при этом новый приоритет не должен быть занят). Для удобства работы, чтобы не нужно было запоминать и определять, каким приоритетом обладает каждая 169

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

2.3. Синхронизация и взаимодействие задач Для синхронизации задач и взаимодействия их друг с другом предусмотрены следующие механизмы:  сигналы;  семафоры;  сообщения;  очереди сообщений. Сигналы. Для уведомления о наступлении какого-либо события задача может послать другой задаче сигнал. Рассмотрим, например, ситуацию, когда задача должна считать данные из порта ввода-вывода. В этом случае можно перевести задачу в режим ожидания сигнала. Когда данные будут готовы, другая задача или процедура обработки прерывания пошлёт соответствующий сигнал, в результате чего первая задача будет активирована и сможет выполнить чтение данных. Семафоры. В MiscoDSP-RTOS реализованы двоичные семафоры и семафоры со счётчиком. Как те, так и другие обычно используются для обеспечения контроля работы с общими ресурсами. Двоичный семафор может принимать значения 1 или 0, что означает, соответственно, доступность и недоступность ресурса. Если задаче требуется доступ к ресурсу, она должна вызвать системную функцию, которая проверяет, доступен ли ресурс. Если он уже занят, то задача переводится в состояние ожидания, а управление передаётся следующей наиболее приоритетной задаче. Если же ресурс доступен (значение семафора равно 1), то он блокируется (значение устанавливается в 0), и управление возвращается в задачу. Когда работа с ресурсом завершена, его нужно освободить вызовом соответствующей функции. При этом из списка всех задач, ожидающих данный ресурс, выбирается наиболее приоритетная и переводится в состояние готовности (а если она имеет более высокий приоритет, чем текущая задача, то происходит переключение). Если таких задач нет, то ресурс просто помечается как свободный (значение устанавливается в 1), и управление возвращается в выполняющуюся задачу. 170

Отличие семафоров со счётчиком от нескольких двоичных семафоров состоит только в том, что ресурсы могут использоваться несколькими задачами одновременно. Например, если есть канал передачи данных, состоящий из четырёх параллельных линий, работающих независимо, то для работы с ним может использоваться семафор со счётчиком, изначально равным 4. Когда задаче требуется линия передачи данных, она делает системный запрос. В результате, если количество доступных линий больше нуля, оно уменьшается на 1; в противном случае задача переводится в режим ожидания до тех пор, пока одна из задач, блокирующих ресурсы, не освободит используемую линию. Стоит отметить, что данный подход существенно отличается от использования нескольких двоичных семафоров. Семафор со счётчиком не делает различия между контролируемыми им ресурсами. В вышеприведённом примере задача, ожидающая ресурс, переводится в состояние готовности при освобождении любой из четырёх линий. При использовании же четырёх двоичных семафоров пришлось бы ждать освобождения какой-то одной конкретной линии, даже если все остальные уже свободны. Сообщения. Сообщения позволяют задачам обмениваться данными. Этот механизм может использоваться, когда одной задаче требуется не только известить другую о наступлении события, но и передать ей какие-то дополнительные сведения (например, уведомление о завершении чтения из порта с указанием адреса буфера, где находятся считанные данные). Принцип действия является таким же, как у сигналов и семафоров: задача, которой требуются данные, вызывает системную функцию, которая определяет, доступны ли данные в запрошенном почтовом ящике. Если данные доступны, то они передаются задаче, и ей возвращается управление. Если же ящик пуст, то задача переводится в режим ожидания. При посылке сообщения проверяется, нет ли задачи, ожидающей получение данных из этого же почтового ящика. Если такая задача есть, она переводится в режим готовности, и при необходимости выполняется переключение задач, если же данные никем не запрошены, они будут храниться в почтовом ящике до первого запроса. Очереди сообщений. Очереди сообщений могут использоваться, когда данные поступают нерегулярно, и неизвестно, будет ли задача успевать сразу считывать все поступающие сообщения. Очередь сообщений организована в виде циклического буфера типа FIFO. Длина очереди, а также количество очередей сообщений, которое может использоваться в программе, задаётся в конфигурационных файлах RTOS-проекта. Работа с очередями организована таким же образом, как и с одиночными сообщениями, с тем лишь различием, что можно хранить не одно сообщение, а несколько.

171

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

2.5. Использование процедур обработки прерываний Из присутствующих в процессоре линий прерывания одна занята самой операционной системой (прерывание таймера для реализации многозадачности). В своей программе разработчик может реализовывать обработку других прерываний, но при этом необходимо иметь в виду некоторые особенности системы. В первую очередь, это возможность запрещать прерывания на некоторое время. Это бывает необходимо в случае, когда программе требуется исключительный доступ к данным, и никакое постороннее вмешательство недопустимо. Например, в большинстве системных функций RTOS в начале кода прерывания запрещаются, а в конце — разрешаются. Это сделано для того, чтобы в процессе изменения внутренних системных данных не могло произойти переключение задачи, что привело бы к ошибкам. Однако этой возможностью не следует злоупотреблять, и крайне желательно, чтобы прерывания не были запрещены в течение длительного времени, поскольку это существенно снижает время реакции системы на внешние события. Важным моментом является также то, что внутри процедур обработки прерываний невозможен вызов функций ожидания. При попытке вызвать такую функцию будет возвращен код ошибки. Посылка же сигналов и сообщений, а также освобождение семафоров внутри обработчиков прерываний допустимо, хотя и требует некоторых дополнительных действий, а именно: в начале процедуры обработки необходимо сохранить контекст 172

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

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

3.1. RTOS Illuminator Этот инструмент представляет собой встроенную утилиту для наблюдения за состоянием процессов и управления ими извне. Визуально RTOS Illuminator является присоединяемым окном в среде MetaDSP, в котором на нескольких вкладках отображено состояние подключённых на данный момент задач. 1. На Рис. 2 показана вкладка Tasks.

статус процесса (Status). Если задача приостановлена или находится в состоянии ожидания, для неё отображается значение таймаута (Delay), а для задач, ожидающих наступления некоторого события, дополнительно указывается, какое именно это событие (Event). Для выполняемой в данный момент задачи также указываются количество тактов, прошедшее с момента последнего переключения на эту задачу (Resumed Cycles), и текущий адрес выполнения (Run Address). Для неактивных задач в поле Run Address выводится адрес программной памяти, с которого будет продолжено выполнение задачи. Двойным щелчком мыши по этому полю можно перейти к тому месту исходного кода, которое соответствует указанному адресу, т. е. по сути, к той точке выполнения, в которой задача была прервана. Помимо этого в этой вкладке можно изменять состояние задач, а именно: а) отключить задачу (команда Disconnect Task в системном меню); б) перевести задачу из режима ожидания, блокировки или приостановленного состояния в режим готовности (команда Make Task Ready); в) изменить приоритет задачи (редактированием значения в поле Priority); г) изменить значение таймаута (при выставлении таймаута в 0 задача, находящаяся в приостановленном состоянии будет переведена в режим готовности, а для задач, ожидающих наступления какого-либо события значение 0 будет означать бесконечное время ожидания); Слева от имени каждой задачи присутствует флажок, включив который, можно установить точку останова, срабатывающую в момент переключения RTOS на эту задачу. Эта функция значительно расширяет возможности отладки многопоточных приложений. 2. На Рис. 3 показана вкладка Events.

Рис. 3. Вид окна RTOS Illuminator, управление объектами синхронизации Рис. 2. Вид окна RTOS Illuminator, управление задачами

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

Она позволяет просматривать текущее состояние процессов: имя процесса (имя подключаемой функции, поле Name), приоритет (поле Priority), текущий 173

174

3.

4.

т. п., поле Type) и список задач, ожидающих данный объект синхронизации (поле Waiting Tasks). Для сигналов и семафоров дополнительно выводится счётчик, представляющий собой текущее состояние объекта (Counter), а для почтовых ящиков и очередей сообщений — указатель на сообщение, если оно присутствует (Message). Так же, как и во вкладке Tasks, слева от каждого объекта присутствует флажок, который включает/отключает точку останова, выполняющуюся при наступлении отмеченного события. Вкладка Stack Info предоставляет информацию о текущем состоянии стека для каждой задачи. Для текущей задачи это будет просто значение стековых регистров, а для всех остальных задач выводятся значения, сохранённые в контексте при переключении. На этой вкладке также отображаются размер стека, процентное соотношение его использования и максимальный процент использования, который был за всё время работы данной задачи. Вкладка RTOS Info отображает сведения о системе RTOS в целом: количество тактов, прошедшее с момента последнего срабатывания таймера, длительность кванта времени, общее число квантов времени, прошедшее с момента старта системы, и версию RTOS.

процессорных инструкций разного типа. С появлением MicroDSP-RTOS были добавлены два новых типа профилировки. 1. Отображение последовательности выполняющихся задач (Рис. 4). Эта вкладка окна профилировщика предоставляет в наглядном графическом виде, какие задачи и в течение какого промежутка времени выполнялись. Промежуток времени указывается как в процессорных тактах, так и в системных квантах времени. 2. Распределение процессорного времени по задачам (Рис. 5).

3.2. RTOS Profiler

Рис. 5. Вид окна RTOS Profiler, распределение времени по задачам В этой вкладке окна профилировщика отображается, какую часть процессорного времени занимала каждая задача. Опционально можно также отобразить суммарное время выполнения для системной фоновой задачи (background), для процедуры обработки таймерного прерывания (RTOS ISR — Interrupt Service Routine), по которому RTOS выполняет переключение задач, и процедуры начальной инициализации (Bootstrap). RTOS-профилировщик позволяет оценить различные показатели разрабатываемого приложения, связанные с мультизадачностью, например, насколько правильно выбран размер кванта времени, выяснить, в течение какого времени система находилась в простое и так далее. Определение значений этих характеристик даёт возможность сравнивать эффективность системы при различных значениях её параметров, что в свою очередь облегчает создание эффективного продукта.

Рис. 4. Вид окна RTOS Profiler, последовательность задач Изначально, до разработки MicroDSP-RTOS, в MetaDSP присутствовал встроенный профилировщик, предоставляющий информацию о распределении процессорного времени между различными функциями внутри программы, а также собирающий статистику по количеству выполненных 175

4. Заключение В настоящей работе была рассмотрена операционная система реального времени MicroDSP-RTOS, разработанная в ИСП РАН для одного из 176

индустриальных партнеров. Данная система предназначена для обеспечения работы многозадачных решений на базе «системы на чипе» c архитектурой MicroDSP. Реализация MicroDSP-RTOS выполнена полностью на языке ассемблера указанного микропроцессора с предоставлением прикладных интерфейсов для программ на языке C. Были рассмотрены основные возможности системы, этапы её развития, особенности поддержки отладки многозадачных приложений в интегрированной среде кросс-разработки. Разработанная система имеет следующие характеристики (для времени выполнения указывается максимально возможное время; для перевода в микросекунды рассматривается процессор с частотой 200 МГц): размер ядра полный размер системы (включая опциональные модули) время сохранения/восстановления контекста длительность ISR (8 задач) длительность ISR (63 задачи)

829 слов 1957 слов 65 тактов (0,33 мкс) 474 такта (2,37 мкс) 2290 тактов (11,5 мкс)

К настоящему моменту работа над MicroDSP-RTOS завершена, результаты внедрены в производство заказчика; в частности, известно о сотовом телефоне, в котором используется данная система. Литература [1] С. Сорокин. Как много ОС РВ хороших… Современные технологии автоматизации, 2/1997, стр. 7–11 (http://www.cta.ru/pdf/1997-2/software1_1997_2.pdf) [2] С. Сорокин. Windows. Современные технологии автоматизации, 2/1997, стр. 18–20 (http://www.cta.ru/pdf/1997-2/software5_1997_2.pdf) [3] С. Сорокин. Системы реального времени. Современные технологии автоматизации, 2/1997, стр. 22–29 (http://www.cta.ru/pdf/1997-2/software6_1997_2.pdf) [4] Comparison between QNX RTOS V6.1, VxWorks AE 1.1 and Windows CE .NET. Dedicated Systems Experts, http://www.dedicated-systems.com. [5] А. Жданов. Операционные системы реального времени. PCWeek, 8/1999 (http://www.asutp.ru/?p=600591). [6] А. Жданов, А. Латыев. Замечания о выборе операционных систем при построении систем реального времени. PCWeek, 1/2001 (http://www.asutp.ru/?p=600493) [7] А. А. Жданов. Что день грядущий нам готовит? (В связи с появлением Windows NT на рынке ОСРВ). http://www.asutp.ru/?p=600308 [8] А. А. Жданов. Современный взгляд на ОС реального времени, (http://www.asutp.ru/?p=600354 ) [9] В. Семенюк. Системы реального времени. http://embedded.ifmo.ru/lib/DOC/REFERATS/HTMLRTOS/rtos97.htm. [10] T. Samuelsson, M. Åkerholm, Department of Computer Science and Engineering; P. Nygren, J. Stärner, L. Lindh. A Comparison of Multiprocessor RTOS Implemented in Hardware and Software. Computer Architecture Laboratory, Mälardalen University, Västerås, Sweden.

177