О концептуальном моделировании
Post on 25-May-2015
1.287 views
DESCRIPTION
Одна из интересных публикаций на темуTRANSCRIPT
![Page 1: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/1.jpg)
О концептуальном моделировании
Б. Тальхайм (Германия)∗
Технологии баз данных и информационных систем претер-пели существенные изменения. В настоящее время повсемест-ное распространение получили системы управления контентом,веб-сервисы с интенсивной обработкой информации, сотруд-ничающие системы, интернет-базы данных, OLAP-базы дан-ных, производящих анализ в реальном времени, и т. п. В то жевремя благодаря широкому применению технология объектно-реляционных данных стала стабильной и хорошо разработан-ной. Концептуальное моделирование (пока) не охватило пере-численные выше области. На протяжении десятилетий основ-ным вопросом концептуального моделирования была специфи-кация структур, тогда как для адекватного представления со-временных систем необходимо также рассматривать вопросыфункциональности, взаимодействия и распределенности. Мно-гие задачи, поставленные еще в 1987 году в работах [13, 14]до сих пор остаются открытыми. В то же время появился це-лый ряд новых технологий, например объектно-реляционнаямодели и модели на основе XML. Новые технологии не решиливсех проблем, скорее расширили и обострили имевшиеся нере-шенные задачи. В работе приводится список открытых задачв классических областях теории баз данных — спецификацияхструктуры и функциональности. Задачи, связанные с взаимо-действием и распределенностью, в настоящее время являютсяпредметом весьма интенсивных исследований.
Постановки открытых задач сопровождается описаниемосновных результатов в области концептуального моделиро-вания. Представляется подход к моделированию объектно-
∗
Bernhard Thalheim. Computer Science and Applied Mathematics Insti-
tute, University Kiel, Olshausenstrasse 40, 24098 Kiel, Germany. Email:
![Page 2: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/2.jpg)
304 Б. Тальхайм
реляционных сотрудничающих систем с поддержкой вирту-альных рабочих групп, интеграции информационных систем,разнообразных архитектур, таких как OLTP-OLAP, play-outи play-in систем и систем анализа данных. Основой работыявляется расширенная модель отношения элементов (Entity-Relationship, ER), покрывающая все структурные возможностиобъектно-реляционных систем и использующая теории медиа-типов и сценариев для спецификации взаимодействия.
1. Введение
1.1. Проектирование и разработка информационных
систем
Проблема создания информационных систем может быть сфор-мулирована следующим образом:Для данной СУБД (или парадигмы базы данных) создать физическуюи логическую структуру информационной системы так, чтобы системасодержала все данные, необходимые для пользователей и для эффектив-ного функционирования системы для всех пользователей. Определитьприкладные процессы базы данных и их взаимодействие с пользовате-лями.
Основными задачами создания баз данных являются:
• удовлетворение всех информационных (контекстных) требова-ний для всех пользователей в данной прикладной области;
• реализация «естественной» и простой для понимания структу-ры хранимой информации;
• обеспечение готовности всей семантической информации длявозможных изменений структуры;
• обеспечение требований к обработке данных и высокой эффек-тивности обработки;
• обеспечение логической независимости запросов и транзакцийна данном уровне;
• предоставление простых и понятных пользовательских интер-фейсов.
![Page 3: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/3.jpg)
О концептуальном моделировании 305
В последние годы велось активное обсуждение структур баз дан-ных. Некоторые проблемы были успешно решены. Однако при рас-смотрении задачи моделирования возникают новые аспекты:
Структурирование приложений баз данных относительно структурыбаз данных и соответствующих статических ограничений це-лостности.
Функционирование приложений баз данных на основе процессов и ди-намических ограничений целостности.
Распределение компонент информационной системы, задаваемое яв-ной спецификацией сервисов и интерфейсов взаимодействия.
Интерактивность (взаимодействие с пользователями), определяемоена основе предполагаемых сценариев работы воображаемыхпользователей, зависящих от типов носителей, используемыхдля выдачи информации пользователям и для обработки по-ступающих данных.
Понимание важности новых аспектов привело к созданию так на-зываемого подхода к соразработке при моделировании на основе спе-цификаций структуры, функциональности, распределения и
интерактивности. Каждый из аспектов имеет как синтаксические,так и семантические элементы.
Однако основную задачу решить так и не удалось.
Открытая задача 1. Найти общую мотивацию, общую формаль-
ную модель и соответствие, удовлетворяющее всем свойствам, и
формализовать характеристики.
1.2. Общие модели информационных систем
Создание баз данных основывается на одной или нескольких мо-делях данных. Часто создание сводится исключительно к структур-ным аспектам. Иногда дополнительно вводится статическая семанти-ка, основанная на статических ограничениях целостности. После реа-лизации структуры происходит спецификация процессов. Поведениепроцессов специфицируется посредством динамических ограниченийцелостности. Далее выполняется разработка интерфейсов. Глубина
![Page 4: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/4.jpg)
306 Б. Тальхайм
теоретической проработки описанных выше этапов существенно раз-личается, как показано в следующей таблице, представляющей дан-ные на конец 90-х годов.
Использованиена практике
Теоретическаяпроработка
Начальныйуровень специ-фикации
Структура хорошо хорошо про-работана
стратегический
Статическаясемантика
частично ис-пользуется
хорошо про-работана
концептуальный
Процессы как-то сделано отдельныемоменты
требования
Динамическаясемантика
отдельные ча-сти
маленькиекуски
реализация
Сервисы реализации частные слу-чаи
реализация
Форматы об-мена
специально дляконкретных си-стем
ничего реализация
Интерфейсы интуитивно ничего реализацияСценарии интуитивно ничего реализация
Создание баз данных требует одновременной согласованной раз-работки структур, процессов, распределений и интерфейсов. Нижемы покажем, как расширенная модель отношения элементов позво-ляет работать со всеми четырьмя аспектами.
В настоящее время базы данных расширяются до информацион-ных web-систем, хранилищ данных, интеллектуальных баз знаний исистем анализа данных. Расширение можно проводить консерватив-ным путем или на основе новых парадигм. Консервативный путь яв-ляется предпочтительным, если только новые парадигмы не позво-ляют решать бывшие нерешенными задачи. В случае использованияконсервативного пути необходима хорошая архитектура [8], [6], поз-воляющая строить расширяемые, масштабируемые системы.
![Page 5: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/5.jpg)
О концептуальном моделировании 307
Открытая задача 2. Найти архитектуру для общего расширения
систем баз данных, позволяющую моделировать все службы и де-
лать выводы о свойствах системы.
В то же время необходимо моделировать качество работы си-стем баз данных. Критерии качества часто задаются весьма нечетко.Распространенными критериями качества являются точность, изме-няемость, отказоустойчивость, удобство, производительность, нераз-глашение, восстановляемость, надежность, эффективность, безопас-ность, стабильность и верифицируемость [4].
Открытая задача 3. Формально определить критерии качества,
атрибуты и метрику для оценки качества для концептуального мо-
делирования, а также разработать средства для внедрения, кон-
троля и улучшения качества.
2. Спецификация структур баз данных
2.1. Языки спецификации структур
Структура баз данных основывается на трех взаимозависимыхкомпонентах:
Синтаксис: Индуктивное задание структуры с использованием мно-жества базовых типов, набора конструкторов и теории приме-нения конструкторов, ограничивающей применение конструк-торов правилами и формулами деонтической логики. В боль-шинстве случаев теория может быть опущена. Структурная ре-курсия является основным средством задания спецификаций.
Семантика: Спецификация допустимых баз данных на основе стати-ческих ограничений целостности описывает легальные состоя-ния баз данных. Если используется структурная рекурсия, дляописания статических ограничений целостности может исполь-зоваться иерархическая логика предикатов первого порядка.
Прагматика: Описание контекста и цели основано либо на явныхссылках на модель фирмы, задачи фирмы, политику фирмы и
![Page 6: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/6.jpg)
308 Б. Тальхайм
окружение, либо на интенциональной логике, задающей интер-претации и значения в зависимости от времени, местонахожде-ния и здравого смысла.
Индуктивное задание структуры основано на базовых типах и кон-структорах типов. Базовый тип представляет собой алгебраическуюструктуру B = (Dom(B), Op(B), P red(B)) с именем, областью до-пустимых значений, множеством операций и множеством предика-тов. Класс BC базового типа представляет собой набор элементов изdom(B). Как правило требуется, чтобы BC было множеством. ТакжеBC может быть списком, мультимножеством, деревом и т. п. Клас-сы могут изменяться под воздействием операций. Элементы классовмогут классифицироваться с помощью предикатов.
Конструктор типов представляет собой функцию из множестватипов в новые типы. В состав конструктора может входить опера-
тор выбора для извлечения данных (например Select) и операторы
обновления данных (например Insert, Delete, Update) для отображе-ния из нового типа в компоненты типов или в новый тип. Операторыобновления могут быть нагружены критериями корректности резуль-тата, правилами верификации, подразумеваемыми правилами, поль-зовательскими представлениями, физическими представлениями илисвойствами физического представления.
В качестве примера типичных для баз данных конструкторовможно привести конструкторы множеств, n-компонентных векто-
ров, списков и мультимножеств. Конструктор множеств основан нанекотором определенном типе и использует алгебру операций, вклю-чающую объединение, пересечение и дополнение. Можно считать,что в этом случае оператор выбора принимает в качестве аргументапредикат. Операторы обновления, такие как Insert или Delete, опре-деляются как выражения в алгебре множеств. В пользовательскомпредставлении используются фигурные скобки { и }. Конструкторытипов определяют систему типов над базовыми схемами данных, тоесть набор конструируемых множеств значений данных. В некоторыхмоделях баз данных конструкторы типов основываются на семантикеуказателей.
![Page 7: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/7.jpg)
О концептуальном моделировании 309
Именование и ссылки также являются удобными средствами кон-струирования в моделях. Каждый тип и класс концепции имеет имя.Эти имена могут быть использованы для для определения новых ти-пов; на имена можно ссылаться при определении типа. Часто струк-туры включают необязательные компоненты. Необязательные ком-поненты и ссылки следует использовать с максимальной осторожно-стью, так как в противном случае потребуется использовать сверх-сложные логики, такие как логики топов [9]. Более удачным подходомк моделированию является требование слабой идентифицируемостипо значениям всех объектов баз данных [10].
2.2. Ограничения целостности
Ограничения целостности используются для отделения «хоро-ших» состояний или последовательностей состояний системы баз дан-ных от нежелательных состояний или последовательностей. Ограни-чения целостности используются для спецификации как семантики,так и процессов в базах данных. Следовательно непротиворечивостьприложений баз данных не может рассматриваться отдельно от огра-ничений. В то же время ограничения целостности задаются пользо-вателем на различных уровнях абстракции, с различными видаминеопределенности и подтекстами, на разных языках. Для обработкии практического использования, однако, ограничения должны бытьопределены явно и однозначно. Для устранения этого противоречияпользовательские ограничения транслируются во внутрисистемныепроцедуры, реализующие поддержание целостности.
В каждой структуре также имеется множество подразумевае-
мых наследуемых из модели ограничений целостности.
Ограничения конструирования компонент основаны на существова-нии, мощности и включении компонент. Такие ограничениядолжны учитываться в процессе трансляции и импликации.
Ограничения идентифицируемости неявно используются в конструк-торе множеств. Каждый объект должен либо не принадлежатьмножеству, либо входить в множество ровно один раз. Множе-ства основаны на простых общих функциях. Свойство иденти-фицируемости, однако, представимо только в терминах авто-
![Page 8: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/8.jpg)
310 Б. Тальхайм
морфизмов групп [1]. Позднее мы увидим, что представимостьзначений и слабая представимость значений влекут за собойконтролируемость структуры.
Ацикличность и конечность структуры поддерживают аксиоматизи-руемость и определенность алгебры. Данные ограничения необ-ходимо выражать явно. Ограничения типа ограничений на мощ-ность могут основываться на потенциально бесконечных цик-лах.
Внешнее структурирование означает представимость ограничений по-средством структуры. В этом случае сложно характеризоватьимпликации ограничений.
Подразумеваемые наследуемые из модели ограничения целостно-сти относятся к фильтрам производительности и поддержания.
Ограничения целостности могут быть сформулированы в терми-нах BV-форм (Beeri-Vardi frames), то есть импликаций, в левой и пра-вой и правой части которой стоят формулы. BV-ограничения, вообщеговоря, не задают строгое ограничение выразимости. Если структураявляется иерархической, BV-ограничения могут быть заданы в рам-ках логики предикатов первого порядка. Можно ввести целый рядклассов ограничений целостности, таких как:
Ограничения для построения равенств позволяют для множества объ-ектов из одного или нескольких классах генерировать равенствасамих объектов или их компонент.
Ограничения для построения объектов требуют, чтобы для множе-ства объектов, удовлетворяющих некоторому условию, суще-ствовало другое множество объектов.
Класс C ограничений целостности называется замкнутым отно-
сительно импликации Гильберта, если он может быть аксиомати-зирован конечным множеством ограниченных правил вывода и ко-нечным множеством аксиом. Известно, что множество зависимостейобъединений не является замкнутым относительно импликации Гиль-берта для реляционных структур. Однако существует аксиоматиза-ция с неограниченным правилом, то есть правилом с потенциальнобесконечным числом посылок.
![Page 9: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/9.jpg)
О концептуальном моделировании 311
Основной проблемой является извлечение ограничений целостно-сти. Так как необходимо обрабатывать множества, возникает необ-ходимость в более сложных теориях вывода. Хорошим кандидатомявляется визуальный или графический вывод, гораздо более силь-ный, чем логический вывод [3].
Открытая задача 4. Создать средство вывода для обработки мно-
жеств ограничений. Классифицировать «реальные» множества
ограничений, которые могут быть легко заданы и поддерживаемы.
Еще несколько проблем, связанных с зависимостями, могут бытьсформулирована на уровне реляционной модели. Приведем соответ-ствующие постановки.
Открытая задача 5. Является ли проблема импликаций для зави-
симостей замыкания и функциональных зависимостей алгоритми-
чески разрешимой? Является ли эта проблема аксиоматизируемой?
Какие подклассы ограничений по включению, содержащие унар-
ные ограничения по включению, аксиоматизируемы вместе с клас-
сом функциональных зависимостей?
Какие подклассы зависимостей объединения, содержащие класс
многозначных зависимостей, являются аксиоматизируемыми?
Охарактеризовать отношения, совместимые по функциональ-
ным зависимостям.
Охарактеризовать свойства классов ограничений при горизон-
тальной декомпозиции.
2.3. Способы представлений
Классический подход к объектам баз данных заключается в хра-нении объектов в зависимости от их типов. Таким образом, каждаясущность оказывается представленной группой объектов, объединен-ных либо с помощью идентификаторов, либо с помощью специаль-ных поддерживающих процедур. Однако, вообще говоря, следует рас-сматривать два различных подхода к представлению объектов:
![Page 10: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/10.jpg)
312 Б. Тальхайм
Поклассовое представление на основе идентификаторов: Хранимые вбазе данных сущности могут представляться несколькими объ-ектами. Идентификаторы объектов поддерживают идентифи-кацию без рассмотрения сложных взаимоотношений между объ-ектами. Объекты могут быть элементами нескольких классов.На раннем этапе развития объектного подхода предполагалось,что такой класс единственный. Подобное допущение приводилок ряду проблем при миграции объектов, не имевших удовлетво-рительного решения.
Описанное выше представление используется в структурах наоснове расширенных ER-моделей [14] и объектно-ориентирован-ных моделей. В реляционных и объектно-реляционных системахбаз данных используется следующий подход:
Пообъектное представление: В графовых моделях, разработанныхдля облегчения применения объектного подхода [1], объектыпредставлены в виде подграфов, то есть в виде совокупностивершин, ассоциированных с объектом, и соответствующих ре-бер. Такое представление соответствует представлению, исполь-зуемому в процессе стандартизации.
XML основан на пообъектном представлении. Он позволяетиспользовать нулевые значения без уведомления. Если значе-ние объекта не существует, неизвестно, неприменимо, не можетбыть получено и т. п., XML-схема не использует тэг, соответ-ствующий атрибуту или компоненте. Классы являются скры-тыми.
Пообъектное представление вносит существенную избыточность,которая должна поддерживаться системой, таким образом суще-ственно снижая производительность. Помимо производительности,проблемами также являются низкая масштабируемость и неэффек-тивное использование ресурсов. Работа с подобными системами при-водит к лавинообразному появлению блокировок — любая модифика-ция данных требует рекурсивной блокировки связанных друг с дру-гом объектов.
![Page 11: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/11.jpg)
О концептуальном моделировании 313
Суммируя вышесказанное, пообъектное представление примени-мо только при выполнении следующих условий:
• Приложение изменяется мало, а структура данных и поддер-живающие основные функции приложения не изменяются напротяжении жизненного цикла системы.
• Обновления данных производятся очень редко. Модификация,вставка и удаление разрешаются только внутри четко опреде-ленных ограниченных «зон» базы данных.
Типичными примерами областей применения систем с пообъект-ным представлением являются архивы, системы представления ин-формации и системы управления контентом. Такие системы строятсяповерх подсистемы обновления данных и называются play-out систе-мами. Данные хранятся в том же виде, в котором они передаютсяпользователю. Подсистема модификации данных содержит play-out-генератор, генерирующий все необходимые просмотры данных дляplay-out системы.
Другим примером являются базы данных без обновлений, такиекак в системе SAP, содержащей огромное число взаимозависимыхпросмотров.
Первое представление может быть использовано для средств по-иска, второе — для ввода и вывода данных в хранилищах данных.
Открытая задача 6. Построить технику и теорию для обра-
ботки избыточных множеств объектов с поддержкой управле-
ния целостностью множеств объектов, например наборов XML-
документов.
Оптимизация баз данных основывается на знании сложности опе-раций. Если известно, что некоторое подмножество операций суще-ственно более сложное, чем остальные операции, и известно несколь-ко эквивалентных представлений, среди таких представлений мож-но найти наиболее простое. Примером оптимизации является верти-кальная нормализация, ориентированная на разложение отношенийна множество отношений, имеющих меньшую сложность и более про-стых в поддержании. Горизонтальная нормализация ориентирована
![Page 12: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/12.jpg)
314 Б. Тальхайм
на выбор частей отношений с наименьшей сложностью. Дедуктивнаянормализация ориентирована на сведение базы данных к отношени-ям, которые не могут быть получены из других отношений приме-нением правил вывода. Напомним, что при нормализации получаю-щиеся представления должны оставаться эквивалентным исходному.В настоящее время описанные виды нормализации рассматриваютсяпо-отдельности.
Открытая задача 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|}|
![Page 13: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/13.jpg)
О концептуальном моделировании 315
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
.
Аналогично можно определить пересечение, объединение, раз-ность, проекцию, соединение, вложение, переименование, вставку,удаление и обновление.
Выразительная сила структурной рекурсии также ограничена.Недетерминированные программы, генерирующие вектора или объ-екты, не могут быть выражены в терминах структурной рекурсии.
![Page 14: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/14.jpg)
316 Б. Тальхайм
Операции могут использоваться либо для извлечения значений,либо для изменения состояния базы данных.
Для определения операций используется подход, основанный напросмотрах, предназначенных для ограничения области значений, атакже предусловий и постусловий, ограничивающих применимость,активизируемых операций, а также явного описания принудительновыполняемых операций: Операция ϕ
[Просмотр: <Имя_просмотра>][Предусловие: <Условие_активации>][Активизируемая_операция: <Спецификация>][Постусловие: <Условие_принятия>][Принудительные_операции: <Операция, Условие>]
Реляционная модель, а также объектно-реляционные модели мо-гут быть расширены за счет добавления операций агрегирования,группировки и ограниченной рекурсии. Семантика перечисленныхопераций варьируется от СУБД к СУБД и до сих пор не получи-ла математического обоснования [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 (внекоторый момент в прошлом).
![Page 15: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/15.jpg)
О концептуальном моделировании 317
Логика первого порядка может быть расширена за счет темпо-ральных операторов. Функция истинности расширяется за счет рас-смотрения времени. Пусть имеется темпоральный класс (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)}.
![Page 16: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/16.jpg)
318 Б. Тальхайм
Ограничения целостности могут накладываться:
• на процедурном уровне, с помощью:
– введения триггеров [7] в так называемые активные на-стройки событие–условие–действие;
– задания максимальных операторов, не нарушающих це-лостности [9];
– хранимых процедур, то есть программ, определяющих всевозможные нарушения ограничений целостности.
• на уровне транзакций, ограничивая последовательности пере-ходов из состояния в состояние последовательностями, не нару-шающими ограничения целостности;
• на уровне СУБД, на основе декларативных спецификаций, за-висящих от возможностей СУБД;
• на уровне интерфейса, путем рассмотрения операций, не нару-шающих целостность.
Ограничения на базы данных отображаются в ограничения напереходы. Ограничения на переходы хорошо изучены, прежде всегоблагодаря их локальности. Такие ограничения могут поддерживатьсяс помощью триггеров или хранимых процедур. Однако вопрос гло-бальных взаимозависимостей остается открытым.
Открытая задача 10. Разработать теорию взаимного влияния
ограничений целостности баз данных, отображаемого на удобные
множества триггеров и хранимых процедур.
3.3. Задание последовательности выполняемых дей-
ствий
В литературе предлагалось значительное количество подходов кзаданию последовательности выполняемых действий. С нашей точкизрения предпочтительным является формальное описание с графи-ческим представлением, позволяющее избегать проблем, связанных сметодами чисто графического задания, такими как и/или ловушки.Рассмотрим алгебру базовых шагов вычисления, введенную в [16].
![Page 17: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/17.jpg)
О концептуальном моделировании 319
• Базовыми управляющими командами являются последователь-ное выполнение ; (выполнение шагов по очереди), распарал-леливание | ∧ | (выполнение шагов в параллельном режиме),исключающий выбор | ⊕ | (выбор одного пути выполнения изнескольких возможных), синхронизация |sync| (синхронизациядвух параллельных путей выполнения с помощью синхронизи-рующего условия sync), и простое слияние + (слияние двух па-раллельных путей выполнения). Исключающий выбор являетсяподразумеваемой параллельной операцией и обозначается ||.
• Структурными управляющими командами являются произволь-ные циклы ∗ (выполнение шагов без каких-либо структурныхограничений на циклы), произвольные циклы + (выполнениешагов без каких-либо структурных ограничений на циклы, заисключением того, что цикл должн быть пройден по крайнеймере один раз), опциональное выполнение [] (выполнение шагаодин раз или пропуск шага), неявное прерывание ↓ (закончитьвыполнение, если больше не осталось шагов), вход в подшаг ↗и завершение подшага ↘.
Расширим алгебру с помощью дополнительного набора команд.
• Дополнительные команды ветвления и синхронизации включаютв себя множественный выбор |(m,n)| (выбрать из всего множе-ства возможных путей выполнения от m до n путей), множе-ственное слияние (слияние нескольких путей выполнения безсинхронизации), дискриминатор (слияние нескольких путей вы-полнения без синхронизации с выполнением последующих ша-гов не более одного раза), объединение n из m (слияние несколь-ких путей выполнения с частичной синхронизацией и выполне-нием следующего шага не более одного раза), и синхронизиру-ющее объединение (слияние нескольких путей выполнения; ес-ли путей несколько, производится синхронизация, в противномслучае выполняется простое слияние).
• Можно также рассмотреть управляющие команды на множествеобъектов (CMO-команды), такие как CMO-команды с получени-ем информации на этапе проектирования (сгенерировать мно-жество реализаций одного шага, причем мощность множества
![Page 18: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/18.jpg)
320 Б. Тальхайм
определяется на этапе проектирования), CMO-команды с полу-чением информации на этапе выполнения (сгенерировать мно-жество реализаций одного шага, причем мощность множестваопределяется в некоторый момент выполнения, как, например,в FOR-циклах), CMO-команды без получения предварительнойинформации (сгенерировать множество реализаций одного ша-га, причем мощность множества неизвестна, как, например, вWHILE-циклах), и CMO-команды с синхронизацией (синхро-низирующие ребра, создать множество реализаций одного дей-ствия и провести синхронизацию после его выполнения).
• Управляющие команды на основе состояний включают отклоня-ющий выбор (выполнить один из двух путей, причем выбира-ется подразумеваемый путь), наложенное параллельное выпол-нение (выполнить два действия в случайном порядке, но не впараллель, а последовательно), и предел (выполнение действийвплоть до достижения некоторого предела).
• Отменяющие команды включают в себя отмену шага, отменуветви и т. п.
Описанные выше операторы являются обобщениями шаблоновпоследовательностей выполняемых действий, созданными в соответ-ствии с подходами, разработанными для алгебр сетей Петри.
Операции, определенные с помощью описанной идеологии, могутбыть непосредственно оттранслированы в программы для баз дан-ных. На данный момент не существует теории поведения баз данных,которая могла бы охватить поведение баз данных во всей широте иглубине. Отправной точкой для создание такой теории, возможно,станет изложенное в работе [15] предложение использовать абстракт-ные машины состояний [2].
Открытая задача 11. Разработать теорию поведения баз данных.
Теория должна охватывать работу как самой базы данных, так и
системы управления базой данных.
![Page 19: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/19.jpg)
О концептуальном моделировании 321
3.4. Архитектура СУБД
Функционирование информационных систем моделируется с по-мощью декомпозиции множества состояний системы на четыре типасостояний:
ERC = (входные состояния IN , выходные состояния OUT ,
состояния СУБД DBMS, состояния базы данных DB)
Входные состояния охватывают входную информацию системы,то есть запросы и данные. Выходные состояния отражают выводСУБД, то есть выходную информацию и сообщения об ошибках. Со-стояния СУБД содержат внутренние состояния системы управления.Состояния базы данных описывают содержимое базы. Все четырекласса состояний могут быть структурированы. Например, если со-стояние базы данных структурируются в соответствии со схемой дан-ных, входные состояния структурируются аналогично.
При использовании ориентированных на значения или объектно-реляционных моделей состояния баз данных могут быть представ-лены отношениями. В этом случае обновление одного из типов схе-мы отображается в изменение одного из отношений. Изменениясостояний моделируются с помощью правил изменения состояний
абстрактных машин состояний [2]. СУБД задается программой иуправлением. Под программой мы будем понимать элементы работыили сервисов, удовлетворяющие заданным критериям качества, подуправлением и координацией — манипулирование блоками программ,возможно с дополнительными требованиями атомарности и непро-
тиворечивости. Также управление и координация могут задаватьсяс помощью команд управления задачами.
При вызове программ производится инициализация значенийвходных переменных. Переменные могут быть статическими, хра-ниться на стеке, задаваться явно или неявно. Дополнительно могутиспользоваться такие параметры вызовов, как onSubmit (ввод зна-чения) и presentationMode (режим презентации), параметры прио-ритета onFocus (фокусировка на процессе) и emphasisMode (режимвыделения), параметры управления onRecovery (восстановление по-сле сбоя) и hookOnProcess (активация процесса), параметры ошибок
![Page 20: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/20.jpg)
322 Б. Тальхайм
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
ζ = истина для всех возможных значенийζ свободных переменных φ.
Рассмотрим две типичных конструкции для порождения про-грамм. Выполнение программы для всех значений, удовлетворяющихнекоторому условию, может быть представлена следующей схемой:
Выполнение программы как шага цикла может быть представленоследующей схемой:
![Page 21: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/21.jpg)
О концептуальном моделировании 323
Дополнительно рассмотрим такие конструкторы, как последова-тельное выполнение, ветвление, параллельное выполнение, выполне-ние после присваивания значений, выполнение после выбора произ-вольного значения, переход на следующий шаг, изменение состоянияинформационной системы и вызов подпрограммы.
Используем абстрактные машины состояний и для определениясемантики программ.
Правило перехода 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. Разработать общую теорию абстракций и
уточнений для систем баз данных, поддерживающую различные ар-
хитектуры и позволяющую декомпозировать базы данных на ком-
поненты.
![Page 22: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/22.jpg)
324 Б. Тальхайм
4. Задание распределения
Задача задания распределения долгое время игнорировалась. Яв-ное задание распределения не применялось, вместо этого использо-вались различные подходы моделирования сотрудничающих систем,такие как системы нескольких баз данных или союзничающие систе-мы баз данных.
4.1. Комплект просмотров
По классическому определению, (простой) просмотр представляетсобой одноэлементный тип, данные которого выбираются из базы понекоторому запросу вида
создать просмотр <имя> (<переменные, на которые проецируется
просмотр>)
выбрать <выражение, задающее проекцию>
из <подсхема базы данных>
где <условие выбора>
сгруппировать по <выражение для группировки>
с <выбор из групп>
упорядочить по <порядок выдачи информации в просмотре>
Так как возможно использование поклассового представления,простые просмотры могут оказаться неоптимальной структурой дляспецификации обмена информацией. Предпочтительной моделью яв-ляется комплект просмотров. Комплект состоит из множества эле-ментов, схемы интеграции или ассоциирования элементов и требова-ний к поддержанию отношения ассоциирования.
Простые примеры комплектов просмотров рассмотрены в рабо-те [14], где в качестве комплектов выступают ER-схемы. Интеграциязадается схемой. Требования к поддержанию основаны на концепции«главный-подчиненный», то есть состояние классов комплекта про-смотров изменяется при изменении соответствующих областей базыданных.
Просмотры должны также реализовывать поддержку сервисов.Сервисы предоставляют свои данные и функциональность. Подобнаяобъектная ориентированность удобна, если возникает необходимость
![Page 23: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/23.jpg)
О концептуальном моделировании 325
использования данных без установления прямого или удаленного со-единения с СУБД.
Рассмотрим обобщенную форму задания просмотра для реляци-онных баз данных:
сгенерировать <отображение: переменные → выходная структура>из <типы базы данных>где <условие выбора>представление с использованием <общий стиль представления>
& <абстракция (гранулярность, мера, точность)>& <упорядочение в рамках представления>& <иерархические представления>& <точки просмотра>& <разделения>
с учетом определений <условие>& <перемещение>
с использованием функций <функции поиска>& <функции экспорта данных>& <функции ввода данных>& <функции сессии>& <функции разметки>
Расширение просмотров за счет функций кажется избыточнымна этапе проектирования баз данных. Использование просмотров враспределенных средах удается минимизировать усилия, связанныес параллельной и последовательной разработкой, так как сразу гене-рируется комплект просмотров вместо того, чтобы отдельно разраба-тывать каждый просмотр.
4.2. Сервисы
Традиционно сервисы изучались в рамках одного из (семи) уров-ней коммуникационных систем и характеризовались двумя пара-метрами: функциональностью и качеством обслуживания. Однакомы используем более современный подход [8] и будем рассматри-вать не функции, а информационные процессы. Качество обслужи-
вания ограничивается рядом свойств, формулируемых или на уровнереализации, или на уровне концепции, или на уровне пользовате-
![Page 24: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/24.jpg)
326 Б. Тальхайм
лей. Сервис состоит из информационного процесса, предоставляемыххарактеристик и свойств, гарантирующих качество обслуживания.Формально сервис представляет собой тройку S = (I,F ,ΣS), гдеI = (V,M,ΣT ).
Информационный процесс задается тремя компонентами:
Просмотры из комплекта V являются ресурсами информационногопроцесса. Так как просмотры расширены за счет функций, ониобладают вычислительными возможностями и могут использо-ваться в качестве статистических пакетов, хранилищ данныхили средств раскопок данных.
Менеджер сервиса M поддерживает функциональность и качествообслуживания и управляет контейнерами, их play-out-функци-ями и доставкой информации клиентам. Менеджеры сервисовтакже называются провайдерами сервисов.
Область применимости сервиса задается в виде множества допусти-мых задач T .
Характеристики сервиса F задаются в зависимости от уровня аб-стракции.
Характеристики на уровне пользователей основаны на соглашенияхуровня сервиса и информационных процессах этого уровня.
Характеристики на уровне концепции описывают свойства, которымисервис должен обладать для выполнения соглашений уровнясервиса. Здесь же задаются доступные клиентам функции пу-тем спецификации интерфейсов и семантики.
Характеристики на уровне реализации описывают синтаксические ин-терфейсы функций, предоставляемые данные, поведение и огра-ничения на информационную систему и клиентов.
Качество обслуживания ΣS задается в зависимости от уровня аб-стракции.
Параметры качества на уровне пользователей включают всеохват-ность (неограниченность доступа в пространстве и времени), ибезопасность (по отношению к сбоям, атакам, ошибкам; степеньдоверенности).
![Page 25: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/25.jpg)
О концептуальном моделировании 327
Параметры качества на уровне концепции включают интероперабель-ность (формальный каркас для интерпретации) и непротиворе-чивость (функций данных).
Параметры качества на уровне реализации включают долговеч-ность (доступ ко всей информации, если не оговорено против-ное), надежность (на основе моделей сбоев для устойчивости,конфликтов и живучести), производительность (на основе мо-дели расходов, времени отклика и пропускной способности), имасштабируемость (по отношению к изменениям сервисов, чис-ла клиентов и серверов).
4.3. Формы обмена информацией
Форма обмена информацией определяется следующими парамет-рами.
Архитектура обмена обычно основывается на архитектуре системы,интегрирующей информационные системы с помощью подси-стем коммуникаций и обмена.
Стиль сотрудничества задает поддерживающие программы, стильвзаимодействия и координирующие средства.
Шаблон сотрудничества задает роли партнеров, права и обязанностии протоколы общения.
Распределенные системы баз данных основываются на локальныхсистемах баз данных, объединенных с помощью заданной стратегиейинтеграции. Основой интеграции является полное объединение ло-кальных концептуальных схем в глобальную схему распределения.Архитектура модели представлена на рис. 1.
Помимо классических распределенных систем можно также рас-смотреть и другие архитектуры, такие как фермы баз данных, нара-
щиваемые сообщества информационных систем и сотрудничающие
информационные системы. Последняя модель основана на концепциисотрудничающих просмотров [14]. Наращиваемые сообщества инфор-мационных систем являются основой систем управления оборудова-нием. Простыми примерами таких систем являются хранилища дан-ных и средства управления контентом.
![Page 26: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/26.jpg)
328 Б. Тальхайм
Рис. 1. Обобщение трехуровневой архитектуры на случай распреде-ленной схемы.
Фермы баз данных являются обобщением и расширением подхода,заложенного в союзничающие информационные системы и системы-посредники. Архитектура ферм баз данных изображена на рис. 2.Фермы основаны на подходе к соразработке и концепциях информа-ционного элемента и контейнера.
Информационные элементы — это обобщенные просмотры. Просмот-ры генерируются на основе содержимого базы данных. Эле-менты — это просмотры, функциональность которых расшире-на, чтобы использовать собственные данные. Информационныеэлементы могут быть ориентированы либо на извлечение, либо
![Page 27: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/27.jpg)
О концептуальном моделировании 329
Рис. 2. Ферма баз данных.
на модификацию данных. Элементы первого типа используют-ся для введения новых данных, элементы второго типа — длямодификации локальных бах данных.
Контейнеры поддерживают экспорт и импорт данных с помощью ин-формационных элементов, предоставленных состояниями про-смотров. Элементы объединяются в контейнеры, которые могутбыть подгружены или выгружены специальным образом. Про-цедура выгрузки поддерживает диалоговые сцены и шаги.
Система глобальных коммуникаций и ферм предоставляет протоколыобмена, средства загрузки и выгрузки контейнеров и средствамодификации элементов данных, ориентированных на модифи-кацию.
Задача полного объединения локальных баз данных не ставится.Задача заключается в создании сотрудничающих просмотров.
Архитектура обмена может включать в себя рабочие области кли-ентов, описывающие участников, группы, роли и права участниковв рамках групп, пакет задач и организацию сотрудничества, комму-никации и взаимодействие.
Стиль сотрудничества определяется четырьмя компонентами:
![Page 28: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/28.jpg)
330 Б. Тальхайм
поддерживающими программами информационных систем, включаю-щими управление сессиями, управление пользователями и си-стему тарификации и оплаты;
шаблонами доступа для передачи данных через сеть, например мно-гоадресная или одноадресная передача, для разделения ресур-сов, на основе либо моделей транзакций, согласия и восстанов-ления, либо репликации с управлением сбоями, и для удаленного
доступа, включая планировщик доступа;
стилем взаимодействия на основе одноранговых моделей или компо-нентных моделей или моделей инициирования событий с огра-ничением на возможные коммуникации;
координацией последовательностей выполняемых действий, описываю-щей сотрудничество партнеров, типы диалогов, отображениепространств имен и правила сотрудничества.
Известен целый ряд шаблонов сотрудничества, поддерживающихдоступ и конфигурирование (оборачивающая фронтальная компо-нента, конфигурирование компонент, перехватчик, расширяющие ин-терфейсы), обработку событий (пререагирование, постреагирование,асинхронные токены завершения, соединение приема), синхрониза-
цию (блокирование подобластей, блокирование с заданной страте-гией, интерфейсы безопасного взаимодействия многонитевых про-грамм, оптимизация блокировок с двойной проверкой) и параллель-
ное выполнение (активные объекты, мониторинг, полусинхронное по-луасинхронное выполнение, ведущий/ведомый, определяемое нитямихранение).
Сотрудничество на основе проксирования использует частичные ко-пии системы (удаленный прокси-сервер, прокси-сервер защиты,кэширующий прокси-сервер, синхронизирующий прокси-сервери т. д.)
Сотрудничество на основе посредников поддерживает координациюкоммуникаций, осуществляемую напрямую, через передачу со-общений, на основе концепций торговли, с помощью системадаптеров-посредников, или с помощью систем отзыва посред-ников.
![Page 29: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/29.jpg)
О концептуальном моделировании 331
Сотрудничество на основе отношения главный/подчиненный использу-ет жесткое реплицирование данных в соответствии с различны-ми прикладными сценариями (отказоустойчивость, параллель-ное выполнение, улучшение точности; реплицирование процес-сов или нитей; реплицирование с координацией или без коорди-нации).
Сотрудничество на основе отношения клиент/координатор основано напространствах имен и их отображении.
Сотрудничество на основе отношения издатель/подписчик также ино-гда называется концепцией зависимости от наблюдателя. Могутрассматриваться как активные, так и пассивные подписчики. Укаждого подписчика имеется профиль подписки.
Сотрудничество на основе отношения модель/просмотр/управлениеаналогично трехуровневой архитектуре систем баз данных.Просмотры и управление задают интерфейсы.
Шаблоны сотрудничества обобщают протоколы за счет включе-ние в рассмотрение партнеров по процессу, их права, ответственностии роли.
5. Спецификация интерактивности
Интерактивность информационных систем как правило рассмат-ривается на уровне систем представления, путем архитектурного илиSeeheim-разделения системы приложений и системы представления.Структура и функциональность задаются в терминах языка моде-лирования баз данных и соответствующей алгебры. Прагматика какправило не рассматривается в рамках моделей баз данных. Интер-активность по отношению к системе приложений основывается намножестве просмотров, определенных на структуре базы данных иподдерживаемых некоторой функциональной базой.
Общая архитектура информационной web-системы представленана рис. 3. Данная архитектура успешно применялась в более чем 30проектах по созданию огромных или очень больший web-сайтов с ин-тенсивной информационной загрузкой и в более чем 100 проектах посозданию больших информационных систем.
![Page 30: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/30.jpg)
332 Б. Тальхайм
Рис. 3. Подход к спецификации информационных систем.
В рамках подхода к соразработке данный подход обобщен за счетследующих добавлений:
введение новых типов объектов (медиа-объектов), по сути являющих-ся обобщенными просмотрами, расширенными с помощью соот-ветствующей функциональности, адаптированными к нуждампользователей и доставляемых участникам с помощью контей-неров [11];
введение пространств сценариев [12], задающих сценарии использова-ния ресурсов различными группами пользователей (называе-мых участниками) в рамках некоторого контекста. Сценариимогут генерироваться на основе реальных действий и с помо-щью различных play-out-средств.
![Page 31: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/31.jpg)
О концептуальном моделировании 333
Модель взаимодействия с пользователями включает несколькихпартнеров (сгруппированных по некоторым признакам; представи-тели групп называются участниками), рассматривает разнообразныедействия и описывает взаимозависимости действий. Помимо последо-вательности шагов взаимодействия, контента шагов взаимодействияи формы взаимодействия модель охватывает также окружение систе-мы, задачи и участников.
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, выполняемое при переходе.
Сцены представляют собой точки, в которых происходит взаимо-действие, то есть диалог. Диалоги могут задаваться с помощью такназываемых выражений шагов диалога. Каждая сцена обладает уни-кальным идентификатором Идентификатор_Сцены. С каждой сце-ной ассоциируется медиа-объект, множество вовлеченных участни-ков, спецификация представления и контекст. Таким образом, сценапредставляет собой следующую структуру:
![Page 32: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/32.jpg)
334 Б. Тальхайм
Сцена = (Идентификатор_СценыВыражение шагов диалогаПользователь
Идентификатор_ПользователяПрава_ПользователяЗадачи_ПользователяРоли_Пользователя
Представление (стили, подразумеваемые значения, . . . )Контекст (оборудование, канал, подробности).
Выражение шагов диалога состоит из диалогов и примененных кдиалогам операторов. Типичная сцена представлена на рис. 4. Участ-ник соревнования по поиску данных может ввести свои решения. Дляучастия в соревновании необходимо внести организационный взнос.Система может знать, а может и не знать пользователя и его про-филь. Если пользователь уже внес организационный взнос, диалогоплаты не выводится. Если же пользователь не внес взнос или неиз-вестен системе, диалог ввода решений доступен только после успеш-ного окончания диалога оплаты.
Рис. 4. Одна из сцен для активного обучения.
![Page 33: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/33.jpg)
О концептуальном моделировании 335
5.2. Комплект медиа-типов
Медиа-типы были введены в работе [11]. Так как разным поль-зователям в зависимости от истории работы, профиля и окружениятребуются существенно отличающиеся данные, пакеты данных пере-даются через контейнеры. Контейнеры обладают всей функциональ-ностью комплектов просмотров. Комплекты медиа-типов основанына комплектах просмотров, снабженных специальными средствамидоставки и извлечения. Комплекты медиа-типов управляются систе-мой, состоящей из трех компонент:
Система извлечения медиа-объектов: Медиа-объекты извлекаются иудаляются из базы данных или базы знаний, обобщаются ивстраиваются в другие медиа-объекты.
Система хранения и поиска медиа-объектов: Медиа-объекты могут ге-нерироваться налету, когда требуется обратиться к их содержи-мому, или храниться в подсистеме хранения и поиска. Так какпорождение медиа-объектов как правило имеет высокую слож-ность, и для нормального функционирование требуется поддер-жание нескольких версий, предпочтительным способом являет-ся хранение.
Система доставки медиа-объектов: Медиа-объекты используются вразнообразных задачах, разнообразными пользователями в раз-личных социальных и организационных контекстах, в разно-образных окружениях. Система доставки медиа-объектов осу-ществляет доставку медиа-объектов пользователям в требуемойформе. Контейнеры содержат и управляют множеством медиа-объектов, доставляемых одному пользователю. Пользовательполучает адаптированный под него контейнер и может исполь-зовать этот контейнер в своей локальной базе данных.
Описанный подход очень близок к концепции хранилищ данных.Он также основан на классической концепции модель–просмотр–управление. Концепция обобщена на медиа-объекты, которые мо-гут просматриваться различными способами, могут генерироватьсяи управляться генераторами.
![Page 34: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/34.jpg)
336 Б. Тальхайм
6. Интегрирование спецификационных ас-
пектов в соразработку
Описанные выше языки довольно сложны, а непротиворечиваяразработка всех аспектов информационных систем трудна. Мы раз-работали ряд методологий, позволяющих обойти ряд трудностей, свя-занных с непротиворечивой и полной разработкой. Основой методо-логий является проектирование сверху вниз (поэтапное уточнение),разделяющее интересующие аспекты на несколько уровней абстрак-ции и использующее операции расширения, детализации, реструкту-рирования и уточнения.
6.1. Модель уровней абстракции для разработки ин-
формационных систем
Информационная система может быть задана на разных уровняхабстракции (рис. 5).
Рис. 5. Модель уровней абстракции процесса разработки баз данных.
![Page 35: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/35.jpg)
О концептуальном моделировании 337
1) Стратегический уровень моделирует цели информационной си-стемы, то есть основную задачу и предполагаемые типы клиен-тов и решаемые ими задачи. Результатом проектирования настратегическом уровне является спецификация организацион-
ного контракта.
2) Уровень выработки требований описывает информационнуюсистему, анализирует бизнес-процессы и цели для формулиро-вания требований к информационной системе. Результатом про-ектирования на уровне выработки требований является специ-
фикация системы.
3) Бизнес-уровень моделирует предполагаемое использование ин-формационной системы в терминах типов клиентов, месторас-положения пространств информации, переходов между про-странствами, а также диалогов между пользователями различ-ных категорий (называемых участниками). Результатом проек-тирования на уровне бизнес-процессов является расширенное
руководство по системе, включающее макеты интерфейсов исценарии использования.
4) Концептуальный уровень ориентирован на интегрированиеконцептуальных спецификаций структуры, функциональности,распределения и интерактивности. Результатами проектирова-ния на концептуальном уровне являются схема базы данных,последовательности выполняемых действий, комплекты про-смотров и медиа-типов, спецификация сервисов и форматов об-мена, а также сценарии.
5) Уровень реализации ориентирован на спецификацию логиче-ских и физических структур баз данных, процедур поддержа-ния целостности, программ и интерфейсов. Спецификация осу-ществляется в рамках языков выбранной платформы. Резуль-татом проектирования на уровне реализации является модель
реализации. Модель существенно зависит от создателя инфор-мационной системы.
6) Уровень использования здесь не рассматривается. Поддержка,обучение, введение и администрирование как правило находят-ся вне сферы концептуального моделирования приложений.
![Page 36: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/36.jpg)
338 Б. Тальхайм
6.2. Методология соразработки
Методологии должны соответствовать требованиям к непротиво-речивой разработке систем SPICE версии 2.0 и SW-CMM версии 2.0.Соразработка основана на пошаговом уточнении системы при дви-жении по уровням абстракции. Так как четыре аспекта информа-ционных систем — структура, функциональность, распределение иинтерактивность — взаимозависимы, они не могут разрабатыватьсяотдельно друг от друга. Приведенная ниже методология основана нашагах следующей структуры:
Используются следующие шаги:Стратегический уровень
1) Разработка видения, целей и задач
2) Анализ проблем и конкурентов
Уровень выработки требований
3) Разбиение на компоненты
4) Создание наброска пространства сценариев
5) Создание наброска комплекта просмотров
6) Задание бизнес-процессов
Бизнес-уровень
7) Разработка сюжетных линий в пространстве сценариев
8) Выявление основных типов данных и ассоциаций между ними
9) Разработка ядра ограничений целостности, например ограниче-ний идентификации
10) Задание действий пользователей, требований используемости, исоздание наброска медиа-типов
11) Выявление требований всеохватности и безопасности
Концептуальный уровень
12) Задание пространства сценариев
13) Разработка типов данных, ограничений целостности, их реали-зации
![Page 37: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/37.jpg)
О концептуальном моделировании 339
Правило #i Задача 1.Имя шага Задача 2.
...
Используемые Документы предыдущих шаговдокументы (документы по разработке системы)
Документация и информация от клиентов
Изменяемые Документы по разработке системыдокументы Контракты
Общие задачи шагаЗадачи и цели Согласованные цели шага
Основная цель
Вовлеченные Участник A, например представители клиентаучастники Участник B, например разработчик
Теория баз данныхТеоретические Теория организацииосновы Информатика
Теория познания, психология, педагогика
Методы и Синтаксис и прагматикаэвристики Используемые языки спецификаций
Подходы к упрощению
Разработанныедокументы
Документы по разработке системы
Результаты Результаты, в том числе поставляемые клиенту
Условия наличия информации,Условия начала выполняемые на стороне клиентовшага Условия зависимости информации
Условия на участие
Условия Полнота и правильность критериевзавершения Подписанные бумаги, контрактышага Критерии качества
Выполнение задач шага
14) Задание комплекта просмотров, сервисов и форматов обмена
15) Проектирование последовательностей выполняемых действий
16) Контроль результатов на тестовых данных, тестовых процессахи тестовых сюжетных линиях
![Page 38: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/38.jpg)
340 Б. Тальхайм
17) Задание комплекта медиа-типов
18) Модулярное уточнение типов, просмотров, операций, сервисови сцен
19) Нормализация структуры
20) Интеграция компонент по всей архитектуре
Требования реализации
21) Преобразование концептуальных схем в логические схемы, про-граммы и интерфейсы
22) Разработка логических сервисов и форматов обмена
23) Разработка решений для повышение производительности, на-стройка
24) Преобразование логических схем в физические схемы
25) Проверка долговечности, надежности, масштабируемости и рас-ширяемости
Методология соразработки использовалась на практике для ре-ализации большого количества информационных систем и вместе стем имеет надежную теоретическую основу. Нашей задачей являетсяне конкуренция с UML, а поддержка разработки систем на твердойоснове, без неясностей, пропусков и несочетаемых концепций.
7. Заключение
Исследования баз данных и информационных систем привели ксозданию технологии, ставшей частью современной инфраструкту-ры. Базы данных используются как встроенные системы, напримерв автомобильных навигационных программах, как совокупность со-трудничающих систем и как одиночные системы. Технология доста-точно хорошо отработана для того, чтобы устанавливать системы базданных в любых приложениях с поддержкой вычислений, основан-ных на обработке большого объема информации. Современные ин-формационные системы часто реализуют поддержку распределенныхвычислений и web-технологии. Новые архитектуры подняли новые
![Page 39: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/39.jpg)
О концептуальном моделировании 341
проблемы, которые в настоящее время являются предметом интен-сивных исследований. В работе показано, как классическая теориябаз данных может быть расширена для решения описанных задач.Отметим, что предлагаемый подход является одним из возможных,могут применяться и другие решения.
В то же время в области исследования баз данных остаются иоткрытые задачи. В работе приведен обзор современных достиже-ний в области теории баз данных, в основном связанных с вопросамиструктуры и функциональности. Некоторые результаты уже непри-менимы к новым моделям информационных систем. Однако остаетсявозможность встраивания классических компонент в новые модели.В первой части работы приведен обзор основных результатов и по-становки открытых задач.
Список литературы
[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.
![Page 40: О концептуальном моделировании](https://reader033.vdocuments.pub/reader033/viewer/2022052900/556345d7d8b42a6f7b8b4938/html5/thumbnails/40.jpg)
342 Б. Тальхайм
[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].