О концептуальном моделировании

О концептуальном моделировании

Б. Тальхайм (Германия)∗

Технологии баз данных и информационных систем претер-пели существенные изменения. В настоящее время повсемест-ное распространение получили системы управления контентом,веб-сервисы с интенсивной обработкой информации, сотруд-ничающие системы, интернет-базы данных, OLAP-базы дан-ных, производящих анализ в реальном времени, и т. п. В то жевремя благодаря широкому применению технология объектно-реляционных данных стала стабильной и хорошо разработан-ной. Концептуальное моделирование (пока) не охватило пере-численные выше области. На протяжении десятилетий основ-ным вопросом концептуального моделирования была специфи-кация структур, тогда как для адекватного представления со-временных систем необходимо также рассматривать вопросыфункциональности, взаимодействия и распределенности. Мно-гие задачи, поставленные еще в 1987 году в работах [13, 14]до сих пор остаются открытыми. В то же время появился це-лый ряд новых технологий, например объектно-реляционнаямодели и модели на основе XML. Новые технологии не решиливсех проблем, скорее расширили и обострили имевшиеся нере-шенные задачи. В работе приводится список открытых задачв классических областях теории баз данных — спецификацияхструктуры и функциональности. Задачи, связанные с взаимо-действием и распределенностью, в настоящее время являютсяпредметом весьма интенсивных исследований.

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

∗

Bernhard Thalheim. Computer Science and Applied Mathematics Insti-

tute, University Kiel, Olshausenstrasse 40, 24098 Kiel, Germany. Email:

[email protected]

304 Б. Тальхайм

реляционных сотрудничающих систем с поддержкой вирту-альных рабочих групп, интеграции информационных систем,разнообразных архитектур, таких как OLTP-OLAP, play-outи play-in систем и систем анализа данных. Основой работыявляется расширенная модель отношения элементов (Entity-Relationship, ER), покрывающая все структурные возможностиобъектно-реляционных систем и использующая теории медиа-типов и сценариев для спецификации взаимодействия.

1. Введение

1.1. Проектирование и разработка информационных

систем

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

Основными задачами создания баз данных являются:

• удовлетворение всех информационных (контекстных) требова-ний для всех пользователей в данной прикладной области;

• реализация «естественной» и простой для понимания структу-ры хранимой информации;

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

• обеспечение требований к обработке данных и высокой эффек-тивности обработки;

• обеспечение логической независимости запросов и транзакцийна данном уровне;

• предоставление простых и понятных пользовательских интер-фейсов.

О концептуальном моделировании 305

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

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

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

Распределение компонент информационной системы, задаваемое яв-ной спецификацией сервисов и интерфейсов взаимодействия.

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

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

интерактивности. Каждый из аспектов имеет как синтаксические,так и семантические элементы.

Однако основную задачу решить так и не удалось.

Открытая задача 1. Найти общую мотивацию, общую формаль-

ную модель и соответствие, удовлетворяющее всем свойствам, и

формализовать характеристики.

1.2. Общие модели информационных систем

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


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

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

Теоретическаяпроработка

Начальныйуровень специ-фикации

Структура хорошо хорошо про-работана

стратегический

Статическаясемантика

частично ис-пользуется

хорошо про-работана

концептуальный

Процессы как-то сделано отдельныемоменты

требования

Динамическаясемантика

отдельные ча-сти

маленькиекуски

реализация

Сервисы реализации частные слу-чаи

реализация

Форматы об-мена

специально дляконкретных си-стем

ничего реализация

Интерфейсы интуитивно ничего реализацияСценарии интуитивно ничего реализация

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

В настоящее время базы данных расширяются до информацион-ных web-систем, хранилищ данных, интеллектуальных баз знаний исистем анализа данных. Расширение можно проводить консерватив-ным путем или на основе новых парадигм. Консервативный путь яв-ляется предпочтительным, если только новые парадигмы не позво-ляют решать бывшие нерешенными задачи. В случае использованияконсервативного пути необходима хорошая архитектура [8], [6], поз-воляющая строить расширяемые, масштабируемые системы.


Открытая задача 2. Найти архитектуру для общего расширения

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

лать выводы о свойствах системы.

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

Открытая задача 3. Формально определить критерии качества,

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

делирования, а также разработать средства для внедрения, кон-

троля и улучшения качества.

2. Спецификация структур баз данных

2.1. Языки спецификации структур

Структура баз данных основывается на трех взаимозависимыхкомпонентах:

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

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

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


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

Индуктивное задание структуры основано на базовых типах и кон-структорах типов. Базовый тип представляет собой алгебраическуюструктуру B = (Dom(B), Op(B), P red(B)) с именем, областью до-пустимых значений, множеством операций и множеством предика-тов. Класс BC базового типа представляет собой набор элементов изdom(B). Как правило требуется, чтобы BC было множеством. ТакжеBC может быть списком, мультимножеством, деревом и т. п. Клас-сы могут изменяться под воздействием операций. Элементы классовмогут классифицироваться с помощью предикатов.

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

тор выбора для извлечения данных (например Select) и операторы

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

В качестве примера типичных для баз данных конструкторовможно привести конструкторы множеств, n-компонентных векто-

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


Именование и ссылки также являются удобными средствами кон-струирования в моделях. Каждый тип и класс концепции имеет имя.Эти имена могут быть использованы для для определения новых ти-пов; на имена можно ссылаться при определении типа. Часто струк-туры включают необязательные компоненты. Необязательные ком-поненты и ссылки следует использовать с максимальной осторожно-стью, так как в противном случае потребуется использовать сверх-сложные логики, такие как логики топов [9]. Более удачным подходомк моделированию является требование слабой идентифицируемостипо значениям всех объектов баз данных [10].

2.2. Ограничения целостности

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

В каждой структуре также имеется множество подразумевае-

мых наследуемых из модели ограничений целостности.

Ограничения конструирования компонент основаны на существова-нии, мощности и включении компонент. Такие ограничениядолжны учитываться в процессе трансляции и импликации.

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


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

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

Внешнее структурирование означает представимость ограничений по-средством структуры. В этом случае сложно характеризоватьимпликации ограничений.

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

Ограничения целостности могут быть сформулированы в терми-нах BV-форм (Beeri-Vardi frames), то есть импликаций, в левой и пра-вой и правой части которой стоят формулы. BV-ограничения, вообщеговоря, не задают строгое ограничение выразимости. Если структураявляется иерархической, BV-ограничения могут быть заданы в рам-ках логики предикатов первого порядка. Можно ввести целый рядклассов ограничений целостности, таких как:

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

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

Класс C ограничений целостности называется замкнутым отно-

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


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

Открытая задача 4. Создать средство вывода для обработки мно-

жеств ограничений. Классифицировать «реальные» множества

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

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

Открытая задача 5. Является ли проблема импликаций для зави-

симостей замыкания и функциональных зависимостей алгоритми-

чески разрешимой? Является ли эта проблема аксиоматизируемой?

Какие подклассы ограничений по включению, содержащие унар-

ные ограничения по включению, аксиоматизируемы вместе с клас-

сом функциональных зависимостей?

Какие подклассы зависимостей объединения, содержащие класс

многозначных зависимостей, являются аксиоматизируемыми?

Охарактеризовать отношения, совместимые по функциональ-

ным зависимостям.

Охарактеризовать свойства классов ограничений при горизон-

тальной декомпозиции.

2.3. Способы представлений

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


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

Описанное выше представление используется в структурах наоснове расширенных ER-моделей [14] и объектно-ориентирован-ных моделей. В реляционных и объектно-реляционных системахбаз данных используется следующий подход:

Пообъектное представление: В графовых моделях, разработанныхдля облегчения применения объектного подхода [1], объектыпредставлены в виде подграфов, то есть в виде совокупностивершин, ассоциированных с объектом, и соответствующих ре-бер. Такое представление соответствует представлению, исполь-зуемому в процессе стандартизации.

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

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


Суммируя вышесказанное, пообъектное представление примени-мо только при выполнении следующих условий:

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

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

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

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

Первое представление может быть использовано для средств по-иска, второе — для ввода и вывода данных в хранилищах данных.

Открытая задача 6. Построить технику и теорию для обра-

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

ния целостностью множеств объектов, например наборов XML-

документов.

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


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

Открытая задача 7. Найти общую модель для применения верти-

кальной, горизонтальной и дедуктивной нормализации для объект-

но-реляционных моделей данных.

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

Открытая задача 8. Найти теорию нормализации, применимую

в случае неполноты множества ограничений.

3. Спецификация функциональности

3.1. Операции в информационных системах

Общие операции над системами типов могут быть определены спомощью структурной рекурсии. Пусть заданы типы T и T ′, мно-жественный тип CT над T (например, множество значений типа T ,мультимножество, список) и операции, такие как обобщенное объеди-нение ∪CT , обобщенное пересечение ∩CT и обобщенный пустой эле-мент ∅CT . Пусть также задан элемент h0 типа T ′ и две функцииh1 : T → T ′ и h2 : T ′ × T ′ → T ′. Тогда операция структурной ре-курсии представления вставки RC над T определяется следующимобразом.

srech0,h1,h2(∅CT ) = h0

srech0,h1,h2(|{|s|}|) = h1(s) для одноэлементных наборов |{|s|}|


srech0,h1,h2(|{|s|}| ∪CT RC) = h2(h1(s), srech0,h1,h2

(RC)),

если |{|s|}| ∩CT RC = ∅CT .

Все операции объектно-реляционной модели, ER-модели, и дру-гих декларативных моделей баз данных могут быть определены втерминах структурной рекурсии, например

• выбор определяется операцией srec∅,iα,∪, где

iα =

{

{o}, если {o} |= α

∅ в противном случае

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

h0f (s) =

{

0, если s = NULL

f(s) в противном случае

hundeff (s) =

{

undef, если s = NULL

f(s) в противном случае

и структурной рекурсии, например

sumnull0 = srec0,h0

Id,+или sum

nullundef = srec

0,hundef

Id,+

;

countnull1 = srec0,h0

1,+или count

undef1 = srec

0,hundef1

,+

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

sumnull0

countnull1

.

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

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


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

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

[Просмотр: <Имя_просмотра>][Предусловие: <Условие_активации>][Активизируемая_операция: <Спецификация>][Постусловие: <Условие_принятия>][Принудительные_операции: <Операция, Условие>]

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

Открытая задача 9. Разработать общую теорию операций, рас-

ширяющих объектно-реляционные модели.

3.2. Динамические ограничения целостности

Динамика функционирования баз данных определяется посред-ством систем переходов. Система переходов для схемы S представ-ляет собой пару T S = (S, {

a−→ |a ∈ L}) где S — непустое мно-

жество переменных состояния, L — непустое множество (меток),a

−→⊆ S×(S∪{∞}) для каждой метки a∈L. Переменные состояниязадают состояния. Переходы представляют собой транзакции в S.

Время жизни базы данных задается в терминах путей в T S. Путь

π в системе переходов представляет собой конечную или счетную по-следовательность вида s0

a1−→ s1a2−→ . . .. Длина пути есть число пе-

реходов.В системе переходов T S можно ввести темпоральную динамиче-

скую логику баз данных, используя кванторы ∀f , (всегда в будущем),∀p (всегда в прошлом), ∃f (в некоторый момент в будущем) и ∃p (внекоторый момент в прошлом).


Логика первого порядка может быть расширена за счет темпо-ральных операторов. Функция истинности расширяется за счет рас-смотрения времени. Пусть имеется темпоральный класс (RC , lR).Функция истинности I расширяется за счет рассмотрения време-ни и определяется на S(tS , RC , lR). Формула α истинна для I(RC ,lR)

в момент tS, если она истинна для базы данных в момент tS ,то есть I(RC ,lR)(α, tS) = 1 тогда и только тогда, когда истиннаIS(tS ,RC ,lR)(α, tS).

• Для формул без темпоральных префиксов расширенная истин-ность совпадает с обычной истинностью.

• I(∀fα, tS) = 1 тогда и только тогда, когда I(α, tS) = 1 для всехt′S > tS ;

• I(∀pα, tS) = 1 тогда и только тогда, когда I(α, tS) = 1 для всехt′S < tS ;

• I(∃fα, tS) = 1 тогда и только тогда, когда I(α, tS) = 1 для неко-торого t′S > tS ;

• I(∃pα, tS) = 1 тогда и только тогда, когда I(α, tS) = 1 для неко-торого t′S < tS .

Модальные операторы ∀p и ∃p (и ∀f и ∃f ) являются двойственны-ми, то есть формулы ∀hα и 6 ∃hα эквивалентны. С помощью следую-щих правил описанные операторы могут быть отображены в класси-ческую модальную логику:

2α ≡ (∀fα ∧ ∀pα ∧ α);

♦α ≡ (∃fα ∨ ∃pα ∨ α).

Можно дополнительно ввести темпоральные операторы until иnext.

Наиболее важным классом динамических ограничений целостно-сти являются ограничения на переход αOβ, задающие предусловие α

и постусловие β для каждой операции O. Ограничение αOβ могут

быть выражено темпоральной формулой αO−→ β.

Произвольное конечное множество статических ограничений це-лостности может быть эквивалентным образом записано в виде мно-

жества ограничений на переход {Λα∈ΣαO−→ Λα∈Σα |O ∈ Alg(M)}.


Ограничения целостности могут накладываться:

• на процедурном уровне, с помощью:

– введения триггеров [7] в так называемые активные на-стройки событие–условие–действие;

– задания максимальных операторов, не нарушающих це-лостности [9];

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

• на уровне транзакций, ограничивая последовательности пере-ходов из состояния в состояние последовательностями, не нару-шающими ограничения целостности;

• на уровне СУБД, на основе декларативных спецификаций, за-висящих от возможностей СУБД;

• на уровне интерфейса, путем рассмотрения операций, не нару-шающих целостность.

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

Открытая задача 10. Разработать теорию взаимного влияния

ограничений целостности баз данных, отображаемого на удобные

множества триггеров и хранимых процедур.

3.3. Задание последовательности выполняемых дей-

ствий

В литературе предлагалось значительное количество подходов кзаданию последовательности выполняемых действий. С нашей точкизрения предпочтительным является формальное описание с графи-ческим представлением, позволяющее избегать проблем, связанных сметодами чисто графического задания, такими как и/или ловушки.Рассмотрим алгебру базовых шагов вычисления, введенную в [16].


• Базовыми управляющими командами являются последователь-ное выполнение ; (выполнение шагов по очереди), распарал-леливание | ∧ | (выполнение шагов в параллельном режиме),исключающий выбор | ⊕ | (выбор одного пути выполнения изнескольких возможных), синхронизация |sync| (синхронизациядвух параллельных путей выполнения с помощью синхронизи-рующего условия sync), и простое слияние + (слияние двух па-раллельных путей выполнения). Исключающий выбор являетсяподразумеваемой параллельной операцией и обозначается ||.

• Структурными управляющими командами являются произволь-ные циклы ∗ (выполнение шагов без каких-либо структурныхограничений на циклы), произвольные циклы + (выполнениешагов без каких-либо структурных ограничений на циклы, заисключением того, что цикл должн быть пройден по крайнеймере один раз), опциональное выполнение [] (выполнение шагаодин раз или пропуск шага), неявное прерывание ↓ (закончитьвыполнение, если больше не осталось шагов), вход в подшаг ↗и завершение подшага ↘.

Расширим алгебру с помощью дополнительного набора команд.

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

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


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

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

• Отменяющие команды включают в себя отмену шага, отменуветви и т. п.

Описанные выше операторы являются обобщениями шаблоновпоследовательностей выполняемых действий, созданными в соответ-ствии с подходами, разработанными для алгебр сетей Петри.

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

Открытая задача 11. Разработать теорию поведения баз данных.

Теория должна охватывать работу как самой базы данных, так и

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


3.4. Архитектура СУБД

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

ERC = (входные состояния IN , выходные состояния OUT ,

состояния СУБД DBMS, состояния базы данных DB)

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

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

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

тиворечивости. Также управление и координация могут задаватьсяс помощью команд управления задачами.

При вызове программ производится инициализация значенийвходных переменных. Переменные могут быть статическими, хра-ниться на стеке, задаваться явно или неявно. Дополнительно могутиспользоваться такие параметры вызовов, как onSubmit (ввод зна-чения) и presentationMode (режим презентации), параметры прио-ритета onFocus (фокусировка на процессе) и emphasisMode (режимвыделения), параметры управления onRecovery (восстановление по-сле сбоя) и hookOnProcess (активация процесса), параметры ошибок


onError (рассмотрение ошибок) и notifyMode (режим уведомлений),а также общие параметры передачи, такие как onReceive (активацияприема) и validUntil (ограничение времени жизни значения).

Требования атомарности и непротиворечивости поддерживаютсяв рамках ряда моделей транзакций. В качестве примера можно при-вести плоские транзакции, сага-транзакции, контракты и т. п. [14].

Пусть T ′ — подтип СУБД ERC . Рассмотрим изменениеT (s1, . . . , sn) := t. Множество U = {Ti(si,1, . . . , si,ni

) := oi|1 6

i 6 m} объектно-ориентированных изменений состояний называет-ся непротиворечивым, если для всех 1 6 i < j 6 m из равенстваTi(si,1, . . . , si,ni

) = Tj(sj,1, . . . , sj,nj) следует равенство oi = oj.

Результатом выполнения непротиворечивого множества U из-менений состояний из ERC является новое состояние ERC + U , длякаждого объекта o из ERC определяемое по формуле

(ERC + U)(o) =

Update(Ti, si,1, . . . , si,ni, oi),

если Ti(si,1, . . . , si,ni) := oi ∈ U

ERC(o)в противном случае.

Параметризованная программа r(x1, . . . , xn) = P арности n состоитиз имени r, правила перехода P и множества свободных переменных{x1, . . . , xn} правила P .

Информационная система ERC является моделью формулы φ

(ERC |= φ), если [[φ]]ERC

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

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

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


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

Используем абстрактные машины состояний и для определениясемантики программ.

Правило перехода P порождает множество изменений состоянийU в состоянии ERC , если U непротиворечиво. Происходит изменениесостояния информационной системы с присваиванием значений пе-ременных ζ, обозначаемое yields(P, ERC , ζ,U).

Семантика правил перехода определяется с помощью исчисленияправил следующего вида:

предусловие1, . . . , предусловиеn

выводгде условие.

Например, изменение состояния, заданное первым из описанныхконструкторов, определяется правилом

∀a ∈ I : yields(P, ERC , ζ[x 7→ a],Ua)

yields(ДЛЯ ВСЕХ x, УДОВЛ. φ, ВЫПОЛН. P, ERC , ζ,∪a∈IUa)

где I = range(x, φ, ERC , ζ).

Диапазон range(x, φ, ERC , ζ) представляет собой множество {o ∈

ERC |[[φ]]ERC

ζ[x→a] = истина}.

Открытая задача 12. Разработать общую теорию абстракций и

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

хитектуры и позволяющую декомпозировать базы данных на ком-

поненты.


4. Задание распределения

Задача задания распределения долгое время игнорировалась. Яв-ное задание распределения не применялось, вместо этого использо-вались различные подходы моделирования сотрудничающих систем,такие как системы нескольких баз данных или союзничающие систе-мы баз данных.

4.1. Комплект просмотров

По классическому определению, (простой) просмотр представляетсобой одноэлементный тип, данные которого выбираются из базы понекоторому запросу вида

создать просмотр <имя> (<переменные, на которые проецируется

просмотр>)

выбрать <выражение, задающее проекцию>

из <подсхема базы данных>

где <условие выбора>

сгруппировать по <выражение для группировки>

с <выбор из групп>

упорядочить по <порядок выдачи информации в просмотре>

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

Простые примеры комплектов просмотров рассмотрены в рабо-те [14], где в качестве комплектов выступают ER-схемы. Интеграциязадается схемой. Требования к поддержанию основаны на концепции«главный-подчиненный», то есть состояние классов комплекта про-смотров изменяется при изменении соответствующих областей базыданных.

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


использования данных без установления прямого или удаленного со-единения с СУБД.

Рассмотрим обобщенную форму задания просмотра для реляци-онных баз данных:

сгенерировать <отображение: переменные → выходная структура>из <типы базы данных>где <условие выбора>представление с использованием <общий стиль представления>

& <абстракция (гранулярность, мера, точность)>& <упорядочение в рамках представления>& <иерархические представления>& <точки просмотра>& <разделения>

с учетом определений <условие>& <перемещение>

с использованием функций <функции поиска>& <функции экспорта данных>& <функции ввода данных>& <функции сессии>& <функции разметки>

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

4.2. Сервисы

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

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


лей. Сервис состоит из информационного процесса, предоставляемыххарактеристик и свойств, гарантирующих качество обслуживания.Формально сервис представляет собой тройку S = (I,F ,ΣS), гдеI = (V,M,ΣT ).

Информационный процесс задается тремя компонентами:

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

Менеджер сервиса M поддерживает функциональность и качествообслуживания и управляет контейнерами, их play-out-функци-ями и доставкой информации клиентам. Менеджеры сервисовтакже называются провайдерами сервисов.

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

Характеристики сервиса F задаются в зависимости от уровня аб-стракции.

Характеристики на уровне пользователей основаны на соглашенияхуровня сервиса и информационных процессах этого уровня.

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

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

Качество обслуживания ΣS задается в зависимости от уровня аб-стракции.

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


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

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

4.3. Формы обмена информацией

Форма обмена информацией определяется следующими парамет-рами.

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

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

Шаблон сотрудничества задает роли партнеров, права и обязанностии протоколы общения.

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

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

щиваемые сообщества информационных систем и сотрудничающие

информационные системы. Последняя модель основана на концепциисотрудничающих просмотров [14]. Наращиваемые сообщества инфор-мационных систем являются основой систем управления оборудова-нием. Простыми примерами таких систем являются хранилища дан-ных и средства управления контентом.


Рис. 1. Обобщение трехуровневой архитектуры на случай распреде-ленной схемы.

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

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


Рис. 2. Ферма баз данных.

на модификацию данных. Элементы первого типа используют-ся для введения новых данных, элементы второго типа — длямодификации локальных бах данных.

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

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

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

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

Стиль сотрудничества определяется четырьмя компонентами:


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

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

доступа, включая планировщик доступа;

стилем взаимодействия на основе одноранговых моделей или компо-нентных моделей или моделей инициирования событий с огра-ничением на возможные коммуникации;

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

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

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

ное выполнение (активные объекты, мониторинг, полусинхронное по-луасинхронное выполнение, ведущий/ведомый, определяемое нитямихранение).

Сотрудничество на основе проксирования использует частичные ко-пии системы (удаленный прокси-сервер, прокси-сервер защиты,кэширующий прокси-сервер, синхронизирующий прокси-сервери т. д.)

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


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

Сотрудничество на основе отношения клиент/координатор основано напространствах имен и их отображении.

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

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

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

5. Спецификация интерактивности

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

Общая архитектура информационной web-системы представленана рис. 3. Данная архитектура успешно применялась в более чем 30проектах по созданию огромных или очень больший web-сайтов с ин-тенсивной информационной загрузкой и в более чем 100 проектах посозданию больших информационных систем.


Рис. 3. Подход к спецификации информационных систем.

В рамках подхода к соразработке данный подход обобщен за счетследующих добавлений:

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

введение пространств сценариев [12], задающих сценарии использова-ния ресурсов различными группами пользователей (называе-мых участниками) в рамках некоторого контекста. Сценариимогут генерироваться на основе реальных действий и с помо-щью различных play-out-средств.


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

5.1. Пространство сценариев

Модели взаимодействия должны поддерживать множество сцена-риев. При этом необходимо учитывать профили и окружение поль-зователей. Сценарий взаимодействия представляет собой сюжет рас-сказа о работе пользователя или перечень событий. Язык SiteLang[16] предоставляет средства для определения пространств сценариев,сцен и сюжетных линий в рамках сценариев.

В рамках сценария можно выделить нити активности, называ-емые сюжетными линиями, то есть пути, составленные из сцени переходов между сценами. Пространство сценариев есть семеркаΣW = (SW , TW , EW , GW , AW , λW , κW ), где SW , TW , EW , GW и AW —множество сцен, созданных W , множество переходов, множество воз-можных событий, множество средств защиты и множество действийW , соответственно. Таким образом, TW является подмножествомSW × SW . Далее, λW : SW → SceneSpec — функция, ассоциирующаяс каждой сценой ее спецификацию, а κW : TW → EW × GW × AW ,t 7→ (e, g, a) — функция, ассоциирующая с каждым переходом t со-бытие e, инициирующего переход t, средство защиты g (то есть логи-ческое условие, блокирующее переход в случае ложности при собы-тии e) и действие a, выполняемое при переходе.

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


Сцена = (Идентификатор_СценыВыражение шагов диалогаПользователь

Идентификатор_ПользователяПрава_ПользователяЗадачи_ПользователяРоли_Пользователя

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

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

Рис. 4. Одна из сцен для активного обучения.


5.2. Комплект медиа-типов

Медиа-типы были введены в работе [11]. Так как разным поль-зователям в зависимости от истории работы, профиля и окружениятребуются существенно отличающиеся данные, пакеты данных пере-даются через контейнеры. Контейнеры обладают всей функциональ-ностью комплектов просмотров. Комплекты медиа-типов основанына комплектах просмотров, снабженных специальными средствамидоставки и извлечения. Комплекты медиа-типов управляются систе-мой, состоящей из трех компонент:

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

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

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

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


6. Интегрирование спецификационных ас-

пектов в соразработку

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

6.1. Модель уровней абстракции для разработки ин-

формационных систем

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

Рис. 5. Модель уровней абстракции процесса разработки баз данных.


1) Стратегический уровень моделирует цели информационной си-стемы, то есть основную задачу и предполагаемые типы клиен-тов и решаемые ими задачи. Результатом проектирования настратегическом уровне является спецификация организацион-

ного контракта.

2) Уровень выработки требований описывает информационнуюсистему, анализирует бизнес-процессы и цели для формулиро-вания требований к информационной системе. Результатом про-ектирования на уровне выработки требований является специ-

фикация системы.

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

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

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

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

реализации. Модель существенно зависит от создателя инфор-мационной системы.

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


6.2. Методология соразработки

Методологии должны соответствовать требованиям к непротиво-речивой разработке систем SPICE версии 2.0 и SW-CMM версии 2.0.Соразработка основана на пошаговом уточнении системы при дви-жении по уровням абстракции. Так как четыре аспекта информа-ционных систем — структура, функциональность, распределение иинтерактивность — взаимозависимы, они не могут разрабатыватьсяотдельно друг от друга. Приведенная ниже методология основана нашагах следующей структуры:

Используются следующие шаги:Стратегический уровень

1) Разработка видения, целей и задач

2) Анализ проблем и конкурентов

Уровень выработки требований

3) Разбиение на компоненты

4) Создание наброска пространства сценариев

5) Создание наброска комплекта просмотров

6) Задание бизнес-процессов

Бизнес-уровень

7) Разработка сюжетных линий в пространстве сценариев

8) Выявление основных типов данных и ассоциаций между ними

9) Разработка ядра ограничений целостности, например ограниче-ний идентификации

10) Задание действий пользователей, требований используемости, исоздание наброска медиа-типов

11) Выявление требований всеохватности и безопасности

Концептуальный уровень

12) Задание пространства сценариев

13) Разработка типов данных, ограничений целостности, их реали-зации


Правило #i Задача 1.Имя шага Задача 2.

...

Используемые Документы предыдущих шаговдокументы (документы по разработке системы)

Документация и информация от клиентов

Изменяемые Документы по разработке системыдокументы Контракты

Общие задачи шагаЗадачи и цели Согласованные цели шага

Основная цель

Вовлеченные Участник A, например представители клиентаучастники Участник B, например разработчик

Теория баз данныхТеоретические Теория организацииосновы Информатика

Теория познания, психология, педагогика

Методы и Синтаксис и прагматикаэвристики Используемые языки спецификаций

Подходы к упрощению

Разработанныедокументы

Документы по разработке системы

Результаты Результаты, в том числе поставляемые клиенту

Условия наличия информации,Условия начала выполняемые на стороне клиентовшага Условия зависимости информации

Условия на участие

Условия Полнота и правильность критериевзавершения Подписанные бумаги, контрактышага Критерии качества

Выполнение задач шага

14) Задание комплекта просмотров, сервисов и форматов обмена

15) Проектирование последовательностей выполняемых действий

16) Контроль результатов на тестовых данных, тестовых процессахи тестовых сюжетных линиях


17) Задание комплекта медиа-типов

18) Модулярное уточнение типов, просмотров, операций, сервисови сцен

19) Нормализация структуры

20) Интеграция компонент по всей архитектуре

Требования реализации

21) Преобразование концептуальных схем в логические схемы, про-граммы и интерфейсы

22) Разработка логических сервисов и форматов обмена

23) Разработка решений для повышение производительности, на-стройка

24) Преобразование логических схем в физические схемы

25) Проверка долговечности, надежности, масштабируемости и рас-ширяемости

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

7. Заключение

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


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

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

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

[1] Beeri C., Thalheim B. Identification as a primitive of datavase mod-els // Proc. Fundamentals of Information Systems, 7th Int. Work-shop on Foundations of Models and Languages for Data and Ob-jects — FoMLaDO’98 (Timmel, Ost-friesland, 1999) / T. Polle,T. Ripke, and K.-D. Schewe, eds. London: Kluwer. P. 19–36.

[2] Borger E., Stark R. Abstract state machines — A method for high-level design and analysis. Berlin: Springer, 2003.

[3] Demetrovics J., Molnar A., Thalheim B. Graphical and spread-sheetreasoning for sets of functional dependencies // In ER’2004 (2004).LNCS 3255. P. 54–66.

[4] Jaakkola H. Software quality and life cycles // In ADBIS’05 (Tallinn,September 2005). Springer.

[5] Lenz H.-J., Thalheim B. Olap databases and aggregation functions// In 13th SSDBM 2001 (2001). P. 91–100.

[6] Lenz H.-J., Thalheim B. OLTP-OLAP schemes for sound appli-cations // In TEAA 2005 (Trondheim, 2005). Vol. LNCS 3888.Springer. P. 99–113.

[7] Levene M., Loizou G. A guided tour of relational databases andbeyond. Berlin: Springer, 1999.


[8] Lockermann P. Information system architectures: From art to sci-ence // Proc. BTW’2003. Berlin: Springer, 2003. P. 1–27.

[9] Schewe K.-D. The specification of data-intensive application systems/ PhD thesis. Brandenburg University of Technology at Cottbus,Faculty of Mathematics, Natural Sciences and Computer Science,1994. Advanced PhD Thesis.

[10] Schewe K.-D., Thalheim B. Fundamental concepts of object orienteddatabases // Acta Cybernetica. 11. 4. 1993. P. 49–81.

[11] Schewe K.-D., Thalheim B. Modeling interaction and media objects// NLDB. Natural Language Processing and Information Systems,5th Int. Conf. on Applications of Natural Language to InformationSystems. NLDB 2000, Versailles, France, Jun 28–30, 2000. RevisedPapers (2001) / M. Bouzeghoub, Z. Kedad, and E. Metais, eds.Vol. 1959 of LNCS. Springer. P. 313–324.

[12] Srinivasa S. A calculus of fixpoints for characterizing interactive be-havior of information systems / PhD thesis. Brandenburg Universityof Technology at Cottbus, Faculty of Mathematics, Natural Sciencesand Computer Science, 2001.

[13] Thalheim B. Open problems in relational database theory // Bull.EATCS 32 (1987). P. 336–337.

[14] Thalheim B. Entity-relationship modeling — Foundations ofdatabase technology. Berlin: Springer, 2000. См. такжеhttp://www.is.informatik.uni-kiel.de/ thalheim/HERM.htm.

[15] Thalheim B. ASM specification of internet information services //Proc. Eurocast 2001, Las Palmas (2001). P. 301–304.

[16] Thalheim B., Dusterhoft A. Sitelang: Conceptual modeling of in-ternet sites // ER (2001). H. S. Kunii, S. Jajodia, A. Solvberg, eds.Vol. 2224 of LNCS. Springer. P. 179–192.

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

Education

О концептуальном моделировании