Введение в системы БД (542480), страница 134
Текст из файла (страница 134)
Подробное описание ОКМ-модели (см, аннотации к двум следующим работам). 13.18.На!р!и Т. Вцздпеьз Ко!ез апд ОЬ)есг-Ко1е Мог1е11пй // РВРАР, № 10, ОсгоЬег, 1996. Великолепное введение в объектно-ролевое моделирование (оЬ)еспго]е люде!1п8 — ОКМ) (!3.17]. Автор начинает с наблюдения, что "(в отличие от] ЕК- модели, для которой существуют десятки разных диалектов, ОКМ-модель имеет лишь несколько диалектов с незначительными различиями".
(Замечание. Один из таких диалектов называется )ч(!АМ-моделью [13.29].) ОКМ-моделирование также называется моделированием на основе фактов, потому что проектировщик начинает процесс моделирования с записи (на естественном языке или с помощью специальных графических обозначений) ряда элементарных фактов (или, точнее, типов фактов), которые в совокупности характеризуют все особенности моделируемой организации. Ниже приводятся некоторые примеры таких типов фактов. ° Каждый работник имеет одно имя.
° Каждый работник отчитывается о своей деятельности перед по крайней мере одним другим работником. Глава 13. Семантическое моделирование 533 ° Если работник е1 отчитывается перед работником е2, то обратное (т.е. работник е2 отчитывается перед работником е1) невозможно. ° Ни один работник не может руководить одним и тем же проектом и оценивать результаты его выполнения. Как видите, типы фактов на самом деле представляют собой предикаты или бизнес-правила. Как следует из названия этой статьи, подход к проектированию базы данных в ОКМ-модели очень близок к тем методам, которые предпочитают сторонники использования "бизнес-правил" [8.18], [9.!9] и сам автор.
В общем случае факты представляют собой роли, выполняемые абъектаии в отношениях между собой (отсюда н название "объектно-ролевое моделирование"). Обратите внимание, что "объекты" в действительности представляют сущности, а не объекты в конкретном смысле этого термина, описанном в части У! этой книги, а связи между ними вовсе не обязательно являются бинарными. Однако факты действительно являются элементарными, т.е.
они не могут быть декомпозированы на меньшие факты. Замечание. Основная идея о том, что база данных на концептуальном уровне должна содержать только элементарные (или неприводимые) факты, принадлежит Холлу (Ной), Оулетту (Очч[еп) и Тодду (ТосЫ) [! 3.1б]. Обратите внимание, что в ОКМ-модели нет понятия "атрибут". В результате, как показано в этой статье, ОКМ-проекты концептуально проще и устойчивее, чем их аналоги, выполненные в КМ-модели (в этой связи см.
также [13.19]). Однако атрибуты могут появляться и действительно появляются при автоматической генерации на основе ОКМ-макета соответствующего Я й:описания проекта или его КМ-макета. В ОКМ-модели также особо подчеркивается использование "фактов-образцов" (т.е. эклетгилрав фактов-образцов, которые иначе можно было бы назвать предлолсгниями) в качестве способа проверки корректное~и проекта со стороны конечного пользователя.
Как утверждается в данной статье, такой подход достаточно просто реализовать при моделировании на основе фактов, но гораздо труднее реализовать при работе с ЕК-моделью. Конечно, существует много логически эквивалентных способов описания данного предприятия и соответственно много логически эквивалентных ОКМ-схем. По этой причине ОКМ-моделирование включает набор правил преобразования, позволяющих выполнять преобразования с получением логически эквивалентных схем. Поэтому ОКМ-инструменты позволяют выполнять некоторую оптимизацию проектов в соответствии с требованиями разработчика. Как уже говорилось выше, с их помощью можно также генерировать БОЕ-описание проекта или его КМ-модель, опираясь на созданную ОКМ-модель, либо выполнять обратную процедуру восстановления ОКМ-модели из БОЕ-описания проекта или его КМ-модели.
В зависимости от используемой СУБД созданное БОЕ-описание проекта может включать объявление ограничений целостности (в стиле КОЕ/92) или предусматривать их поддержку с помощью хранимых процедур или триггеров. В отношении ограничений отметим, что в отличие от ЕК-модели ОКМ-модель по определению содержит "развитый язык для формулирования ограничений". (Однако в [13.!9] автор признает, что не все бизнес-правила можно выразить с помощью принятых в ОКМ- модели графических обозначений.
Для некоторых из них все же придется использовать текстовые формулировки.) 534 Часть 111. Проектирование базы данных Наконец, ОКМ-модель, безусловно, может рассматриваться как высокоуровневое абстрактное представление базы данных (на самом деле следовало бы возразить, что оно, скорее, ближе к чистому, возможно, даже в некоторой степени строгому, реляционному представлению). Благодаря этому появляется возможность задавать запросы непосредственно ей самой 113. 19!. 13.19На!рщ Т.
Сопсер!ца! Оцег!ез // Оа!а Вазе Незчз!ецег, 26 № 3, Матей-Арг!1, 1998. Цитата из аннотации к этой работе: "Формулировка нетривиальных запросов с помощью таких реляционных языков программирования, как ЯОЬ и ОВЕ, может оказаться очень сложной задачей для конечных пользователей. Язык СолДке«является новым концептуальным языком создания запросов, который основан на объектно-ролевом моделировании и предоставляет простой и понятный пользователям способ формулирования запросов...
В этой статье описаны преимушества [такого языка! по сравнению с традиционными языками запросов в отношении формулирования запросов и бизнес-правил". Помимо всего прочего, в статье обсуждается приведенный ниже запрос на языке СопОцег, смысл которого состоит в следующем: "Извлечь данные о работниках, которые водят машину, и об отделах, в которых они работают". "'Работник +-водит Машину +-работает в ~Отделе Если сотрудник в общем случае умеет управлять произвольным количеством машин, а работать может толькод одном отделе, то базовая ЯОЬ-схема может состоять из двух таблиц, а соответствующий ЯОЬ-запрос иметь следующий вид.
ЯЕБЕСР 01Яз1НСт Х1.ЕМР№, Х1.ВКАМСН№ РВОМ ЕМРБОУЕЕ АЯ Х1, ОК1ЧЕЯ АЯ Х2 ННЕКЕ Х1.ЕМР№ = Х2.ЕМР№ Теперь предположим, что служащий может работать одновременно в нескольких отделах. Тогда базовая ЯОЬ-схема должна включать не две, а три таблицы, а соответствующий ЯОЬ-запрос будет иметь следующий вид. ЯЕЬЕСР О1Яз1НСз Х1.ЕМР№, ХЗ.ВКАНСН№ РКОМ ЕМРБОУЕЕ АЯ Х1, РК1ЧЕЯ АЯ Х2, НОНКЕ РОК АЯ ХЗ ННЕКЕ Х1.ЕМР№ = Х2.ЕМР№ АНО Х1.ЕМР№ = ХЗ.ЕМР№! Однако в запрос на языке СопОцег никаких изменений вносить не потребуется. Как видно из предыдущего примера, язык СопОцег может рассматриваться, как весьма строгий вариант реализации логической независимости от данных, Для объяснения этого замечания придется несколько уточнить архитектуру АНЯ!/БРАКС !2.1Ь !2.21 Как говорилось в главе 2, логическая независимость от данных означает независимость от изменений концептуальной схемы, но дело в том, что в предыдущем примере не было сделано никаких изменений концептуальной схемы! Причина в том, что современные БОЬ-продукты поддерживают работу с концептуальной схемой не совсем должным образом.
Вместо этого они, скорее все~о, поддерживают работу с 5Дь-схемой. При этом Я ПЬ-схема может рассматриваться как некий промежуточный уровень между истинным концептуальным 535 Глава 13. Семангпичеекое моделирование уровнем и внутренним или физическим уровнем. Если ОКМ-инструмент позволяет определить истинную концептуальную схему и отобразить ее на 3()(,-схему, то язык СопОцег может обеспечить требуемую независимость от изменений в БО1 схеме (конечно, при соответствующих изменениях этого отображения).
Из статьи не совсем ясно, чем ограничивается выразительная мощь языка СопЯцег. Автор статьи не дает прямого ответа на поставленный вопрос, но отмечает, что "этот язык позволяет идеально формулировать любые вопросы, которые имеют какое-то отношение к данному приложению; причем иногда на практике достаточно и меньше того, что он предоставляет".
К тому же автор заявляет, что "наиболее мощной функциональной возможностью языка СопЯцег... является его способность выполнять корреляции с произвольным уровнем сложности", и приводит следующий пример. ГРаботиик1 +-живет в Городе1 +-родился в Стране1 +-руководит работой Работника2, который +-живет в Городе1 +-родился в Страие2 <> Стране1 Этот запрос означает: "Извлечь данные о сотрудниках, руководящих работой других сотрудников, которые живут в том же городе, что и их руководитель, но родились в дру~ой стране". Автор предлагает попробовать сформулировать этот запрос на языке Я)Ь! Наконец, в отношении языка СопОцег и бизнес-правил автор говорит: "Хотя графические обозначения ОКМ-модели могут выразить больше бизнес-правил, чем [ЕК- модель), их все еще приходится дополнять текстовым описанием !для выражения некоторых ограничений).
В настоящее время продолжаются исследования, проводимые в направлении адаптации языка СопОцег для достижения указанной цели". 13.20.Напппег М.М., МсЬеог! Р.1. ТЬе Бешапбс Рага Мог!е1: А Мобе!!!п8 МесЬапюп Гог РагаЬазе Аррйсайопз // Ргос. 1978 АСМ Б!ОМОР !пгегп. Сопб оп Мапайегпепс оГ Рага. — Ацзг!и, Техаз.
— Мау-)цпе, 1978. Семантическая модель данных (Бетапбс Рага Мобе! — 8РМ) представляет собой другой формальный подход к проектированию базы данных. Как и в случае ЕК- моделирования, в этой модели основное внимание уделяется структурным аспектам и аспектам целостности и совсем немного внимания (или вообще никакого)— аспектам манипулирования данными (операторам). Об этом также можно прочесть в (! 3.21), (! 3.24).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
