Моделирование взаимосвязей между сущностями

Альтернативные модели сущностей и их отражение в проекте

Рассмотренные соглашения по моделированию не исключают применение различных способов построения моделей. Рассмотрим три таких альтернативных способа с точки зрения их реализации в проекте.
Рисунок F-6. Альтернатива 1

Рисунок F-7. Альтернатива 2

Более предпочтительная модель, поскольку в ней ощутимо присутствие подтипов A1 и A2. Теперь при реализации внешних ключей нет необходимости думать о том, на какую "родительскую" сущность указывает связь.
Рисунок F-8. Альтернатива 3

Тоже более предпочтительна по сравнению с первой альтернативой, поскольку уникальный идентификатор D может использоваться как для B, так и для C. Разумеется, все это в том случае, если супертип D действительно существует.
Альтернативы 2 и 3 дают нам возможность проверки существования понятий, обозначаемых подтипами A1 и A2 (с учетом их атрибутов/связей и функций) и супертипом D (с учетом его атрибутов и т. п.).

Атрибут

Определение атрибута
Атрибутом назовем

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

либо

любое описание объекта или явления

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

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

В нашем примере авиалинии могут потребоваться самолеты только четырех или пяти различных типов, самих же самолетов может оказаться и сто, и больше. Атрибут "регистрационный номер" имеет значение, уникальное для каждого вхождения сущности САМОЛЕТ.

Для того, чтобы считать анализ информационного содержимого атрибута завершенным, мы должны иметь следующее:

наименование

описание

формат

длину

значение и/или диапазон принимаемых значений

а также все, что связано с этим атрибутом:

сущность

уникальный идентификатор(ы)

функции, в которых он используется.

Полностью определение атрибута показано в Приложении C.

Производный атрибут

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

Так, например, модель для авиакомпании содержит связь между САМОЛЕТОМ и расположенными в нем МЕСТАМИ. Одним из возможных производных атрибутов для сущности САМОЛЕТ будет атрибут "количество мест". Этот атрибут принимает значение в результате выполнения функции "подсчета количества МЕСТ в САМОЛЕТЕ".

Другой пример - производный атрибут "фактически уплаченная сумма" для сущности БИЛЕТ, значение которого вычисляется из значений атрибутов "полная стоимость" и "принятая скидка".

С этим понятием связаны некоторые опасности, уяснить которые необходимо прежде, чем вы приступите к проектированию БД.

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

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


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

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

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

Например:

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

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

Другие возможные характеристики атрибута

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

фотография

отпечаток пальца

звук

цвет

спектрографические данные

запах

вкус

изображение

видеокадр

пульс

и т.п.

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

Присвоение наименований

Наименование атрибута должно быть простым и понятным, не содержать имени сущности и даваться в единственном числе. При развернутом чтении наименования атрибута вы можете воспользоваться одной из следующих форм:

Имя сущности Название атрибута

или

Название атрибута Имя сущности

Рисунок 7-19. Пример



Наименование атрибута - просто "дата", но оно всегда используется в контексте сущности РЕЙС. В описании функции на него можно сослаться следующим образом: "проверить дату рейса".

Цель

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

Что такое метамодель?

Метамодель, говоря проще, это модель модели.
Мы построили модели для таких понятий, как кредитная карточка, счет, рейс, купон и личность.
Метамодель же будет включать в себя схемы и определения, имеющие отношение к понятиям сущности, атрибута, домена, связи и многим другим, упоминавшимся в Главе 9 и в Глоссарии. Отношения между основными понятиями данной книги можно изобразить простой схемой:
Рисунок H-1. Простая метамодель

Трактовка метамоделей
Метамодели трактуются подобно обычным моделям. Например:
Каждая СУЩНОСТЬ может быть подтипом одной и только одной СУЩНОСТИ и супертипом по отношению к двум и более СУЩНОСТЯМ.
Она может описываться одним и более АТРИБУТАМИ, каждый из которых может входить в один и только один ДОМЕН.
Кроме того, каждая СУЩНОСТЬ может быть субъектом одной и более СВЯЗЕЙ, каждая из которых входит в другую или ту же СУЩНОСТЬ.
Большинство рассмотренных метапонятий представлено на следующей схеме:
Рисунок H-2. Метамодель, состоящая из понятий, рассмотренных в книге

Цикл жизни сущности

Если наша модель взаимосвязей между сущностями содержит, к примеру, сотню сущностей, было бы очень полезно с точки зрения контроля ее качества выбрать десять наиважнейших из них и рассмотреть их жизненные циклы. Это поможет вам обнаружить пропущенные атрибуты, связи, сущности, события и функции, воздействующие на них.
Так, например, цикл жизни сущности ПРОДУКТ может включать в себя следующее:

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

описание требований к продукту

проектирование продукта

изготовление макета (опытного образца)

тестирование (испытание) продукта

создание установки для производства продукта

получение промышленных образцов

изучение рынка и продажа

и т.п.

В результате мы можем открыть новую сущность ОПЫТНЫЙ ОБРАЗЕЦ ПРОДУКТА и перейти к ее анализу.
Другие понятия
Существует масса других понятий, которые необходимо усвоить, прежде чем приступать к созданию полной системы. Они рассматриваются в других книгах и разбираются на занятиях.

Денормализация данных

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

Домен

Определение понятия
Доменом называется совокупность правил проверки соответствия, форматных ограничений и других свойств (характеристик), присущих группе атрибутов.
Например:

список значений

диапазон

уточненный перечень значений или диапазон

любая комбинация из вышеперечисленного.

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

строка адреса

почтовый код/индекс

класс (часто со списком значений)

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

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

		ДОМЕН
Адресная строка-1		Адрес
Адресная строка-2		Адрес
Адресная строка-3		Адрес
Город		Адрес
Графство (или штат)		Адрес
Страна		Адрес
Почтовый код (или индекс)		Почтовый код

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

Функциональный пример

С помощью схемы определим функциональный аспект задачи: Производство назначений в экипажи на конкретные рейсы людей, могущих выполнять определенные роли, базирующиеся как на стандартных требованиях к члену экипажа самолета данного типа, так и на дополнительных требованиях, которые определяются особенностями авиамаршрута.
Эта задача может быть "прочитана" и непосредственно по схеме, но для большей ясности мы убрали некоторые усложняющие суть слова и выражения.
Следует заметить, однако, что большинство понятий, используемых в нашей постановке, выбрано из схемы. Задачу легко поставить, если описания связей даются в пассивной форме (а для английского написания, кроме того, используется правило, в соответствии с которым связующие фразы должны содержать глагол to be - must be или may be).
Стандартные экипажи
Члены экипажа могут быть сгруппированы в экипажи, выполняющие полеты постоянно в одном и том же составе. В этом случае указанная задача должна включать в себя попытку назначения в экипаж не стандартным способом, а так как это делается обычно. Введем новое понятие - непереносимая связь, которая на схеме обозначается символом --<>--.
Рисунок 6-9. Составление обычного экипажа

Обратите внимание на то, что схема теперь содержит перечень экипажей, обычно назначаемых на самолеты данного типа (связь типа "многие ко многим" между ЭКИПАЖЕМ и ТИПОМ САМОЛЕТА). Отсюда легко установить состав каждого экипажа и распределение обязанностей (ролей) внутри него.
Непереносимые (нетрансферабельные) связи
Множество связей описано как непереносимые (нетрансферабельные), т.е. такие, которые раз возникнув в виде отношения с одним из экземпляров, уже не могут быть перенесены на другие экземпляры или вхождения данной сущности.
Рассмотрим этот вопрос на примере с атрибутами сущности ДОЛЖНОСТЬ В ОБЫЧНОМ ЭКИПАЖЕ:

дата вступления

дата ухода

особые обязанности.

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

является методом описания информационных запросов,

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

УЧЕБНЫЙ ПРИМЕР

Прежде чем перейти к теории МВМС, рассмотрим пример из жизни некой гипотетической компании и его интерпретацию средствами моделирования. Затронем также и некоторые аспекты реализации модели.
Используемые в этой главе понятия подробно объясняются в Главе 3 и в Глоссарии.

ОСНОВНЫЕ СОГЛАШЕНИЯ И ОПРЕДЕЛЕНИЯ

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

ВТОРОЙ ПРИМЕР

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

ИДЕНТИФИКАЦИЯ СУЩНОСТЕЙ, АТРИБУТОВ И СВЯЗЕЙ

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

СЛОЖНЫЙ ПРИМЕР

Вернемся к компании "Atlantis Island Flights" и разберем некоторые более общие положения моделирования.

ДОПОЛНИТЕЛЬНЫЕ СОГЛАШЕНИЯ И ОПРЕДЕЛЕНИЯ

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

подтипы

супертипы

различия между подтипами

пересечение подтипов

справочные и граничные сущности

определение

объемы за период времени

распределенное требование

Для связи

разделение отношения "многие ко многим"

исключительность (эксклюзивность)

непереносимость

уточненный тип

определение

избыточность

подходящие описания

каскадное удаление (и коррекция)

А также понятия:
Уникальный идентификатор;

по дуге

Домен

определение

детали и применение

Атрибут

определение

производный

КЛАССИЧЕСКИЕ СТРУКТУРЫ И ОБОБЩЕНИЯ

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

иерархий/организационных единиц

сетей

регистрации (истории) изменений

перечня материалов

классификации и категорий

типологии сущностей.

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

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

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

РОДСТВЕННЫЕ ПОНЯТИЯ

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

поток данных

хранилище данных

управленческая функция

управленческое событие

схемная архитектура

цикл жизни сущности.

Групповой контроль

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

Идентификация атрибутов

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

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

либо любое описание объекта или явления.

Если вы уже идентифицировали сущность, лучшим способом перейти к идентификации ее атрибутов будет вопрос, заданный пользователю:
"Какую информацию вам нужно получить или сохранить относительно........?"
К сожалению, они дадут вам ответы, содержащие в себе другие понятия, поэтому вам еще придется подробно проанализировать каждый ответ. Помните определения и строго соблюдайте все соглашения.
Бумажные формы
Потенциальные атрибуты содержатся прежде всего в бумажных формах. Выберите из бланков заголовки и подсказки. Также проанализируйте уже заполненные формы, обращая внимание на дополнительную информацию, записанную на обороте и в разделе примечаний. Но будьте внимательны. Один и тот же атрибут может появиться в разных формах под разными именами.
Компьютерные файлы
Компьютерные файлы, определения КОБОЛа, схемы БД, экранные формы и т.д. изобилуют информацией, которую можно анализировать. Здесь могут помочь методы нормализации данных (см. Приложение A). На практике одни и те же данные повторяются многократно с акронимами, сокращениями, в префиксной записи - в соответствии с прихотью программиста, стандартами инсталляции или ограничениями, накладываемыми на программное обеспечение (например, 8 символов на имя).
Существует опасность, что при анализе бумажных форм и существующих компьютерных файлов вы заложите устаревшие требования как новые. Чтобы избежать этого, всегда стройте модель, ориентируясь прежде всего на интервью, и только затем сравнивайте модель с существующими системами на предмет поиска упущений.
Осуществив такой "восходящий" контроль, обратитесь к пользователю вновь, на этот раз с вопросом: "Это все, что вам действительно нужно?"

Примеры и идентификаторы

Если вы снова обратитесь к фрагменту, взятому нами из интервью, вы сможете обнаружить множество примеров появления атрибутов:



Обратите внимание на то, что "British Airways" - возможный уникальный идентификатор для компании (в данном случае авиалинии).

"Боинг-747" может быть атрибутом самолета или может указывать на то, что нам нужна новая сущность, именуемая ТИП САМОЛЕТА; в последнем случае "747" станет значением атрибута "код".

ТИП САМОЛЕТА код, например - 747

описание

максимальная нагрузка

Атрибуты в тексте

Из интервью видно, что многие атрибуты присутствуют в нем непосредственно, но нужно еще установить связь между ними и сущностями. Задайте себе по поводу каждого из них простой вопрос: "Что описывает он?"

Что описывает атрибут "стоимость"?	Билет или, возможно, стандартную стоимость маршрута
Что описывает атрибут "дата"?	Рейс или оформление билетов.
К чему относится атрибут "скидка"?	Снова к билету; может быть некоторой формой стандарт-соглашения для коллективных заявок (пропущена сущность?)

Производные данные

Как в компьютерных, так и в неавтоматических системах имеют место производные данные многих видов - в частности, ими изобилуют отчеты и итоговые формы. В МВМС производные данные появляются редко, поскольку нам достаточно тех атрибутов, из которых они получаются ("производятся").

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

Идентификация сущностей

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

набор инструкций для ЭВМ

ряд событий

курс обучения

план достижения цели

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

план телепередач.

Зачастую в своей речи люди ссылаются на роли, исполняемые объектами, в особенности это относится к отдельным лицам и к организациям. Такими ролями иногда являются профессии, уровни неофициальной ответственности и имена тех людей, с которыми мы контактируем. Приведем несколько примеров ролей, которые может исполнять отдельная личность: менеджер, клерк, секретарь, офицер службы безопасности, мать, лидер, руководитель группы, тренер, авиапилот, политик, гуру, приемщик, ребенок, машинист, жертва обмана, адвокат, ученый, дворник, клоун, авиадиспетчер, эколог.
Использование множественного числа и других грамматических тонкостей также требует особого внимания.
Кроме того, даже в одном языке написание слов может различаться в зависимости от страны, например (в английском): aeroplane/airplane; colour/color; sulphur/sulfur.

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

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

Пример:

Сущность ЛОКОМОТИВ имеет синоним ПОЕЗД и примеры: "The Flying Scotsman", "Puffing Billy", "Stephenson's Rocket" и более свежий пример - японский монорельсовый Bullet.

Анализ результатов интервьюирования

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

Вопрос: Расскажите мне о различных способах, с помощью которых можно приобретать билеты.

Ответ: В большинстве случаев звонят в трансагентство и рассказывают о путешествии, которое хотели бы предпринять. Иногда все решается просто. Хотят, к примеру, взять билет на рейс British Airways 747 до Парижа на определенную дату. Чаще, однако, обсуждаются все "за" и "против" каждой авиалинии, каждого рейса (времени отправления, аэропорта приземления) - должностные лица могут даже зафрахтовать целый самолет и приземлиться на местном аэродроме или на отдельной посадочной полосе. Агент прорабатывает расписание, по возможности учитывающее желательное время прибытия, проверяет наличие окна в рейсах, набирает пассажиров, выделяет места и после этого выписывает билеты. Стандартная ситуация имела место вчера, когда вошедший пассажир попросил билет до Сан-Франциско с открытой датой отправления - после 10-го июня, с тем чтобы иметь возможность организовать свою поездку позднее и сэкономить на оформлении.

....

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


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

....

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



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

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

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

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

Что нам подсказывает здравый смысл

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

Если вернуться к нашему примеру и представить себе, что вы находитесь в трансагентстве - что вы увидите вокруг? Очевидно, столы, кресла, стойку, телефоны, двери, окна и т.п.

Все это может не представлять интереса, если не принимать во внимание имущественный аспект.

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

брошюры

расписания

карты

бланки заказов

условия предоставления кредита

процедура обмена

и т.п.

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

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

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

"А как можно уникально определить...............?"

Идентификация связей

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

пассажир, указанный на билете

заказан (кем-то)

исправлен (кем-то)

проверен (кем-то)

выдан (кем-то).

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

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

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

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

Рисунок 5-4. Образец бланка заказа, используемого в отделе поставок

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

Заказ на приобретение со Строкой (из множества строк, соответствующих позиции)

Строка с Позицией (или Продуктом)

Доставка с Позицией или Заказом

Заказ подписывается Личностью

Заказ с Поставщиком

Заказ с Отделом поставок

Только одна связь имеет описание, но несмотря на это уже теперь вы можете построить модель, используя имеющуюся информацию:

Рисунок 5-5. Модель для бланка заказа



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

Метод решетки

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



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

Компьютерные файлы

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

указателям

внешним ключам

повторяющимся группам

структурным кодам

т.е. всему тому, что указывает на наличие связей.

Иерархии

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

Рисунок 8-2. Элементарная модель

Такая модель будет правильной, только если группы не могут входить непосредственно в состав отделений, а отделы неподотчетны перед компанией непосредственно, а также если цепочка Группа-Отдел-Отделение-Компания является исчерпывающей. Что же произойдет, если мы добавим еще один уровень?
Рисунок 8-3. Альтернатива 1

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

Такая модель тоже подойдет для любого числа уровней. Каждый уровень может иметь свой определенный тип, таким образом допускается использование большого количества альтернативных наименований уровней. Выделение вершины иерархии (КОМПАНИИ) позволяет осуществлять для нее индивидуальный учет связей и функций, в которых она участвует.
Рисунок 8-5. Альтернатива 3

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

Этот путь приведет нас к созданию обобщения высокого уровня, учитывающего самые исключительные требования.
Рисунок 8-7. Альтернатива 4. Обобщенная модель

Существует одно важное "но" - в 99% случаев функции имеют дело с ныне существующей (текущей) структурой, а не с предполагаемой в будущем или существовавшей в прошлом.
Поэтому станем реалистами и соединим альтернативы 3 и 4 вместе.
Рисунок 8-8. Альтернатива 5

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

Интуитивная нормализация

Если вы посмотрите на получившуюся модель внимательно, вы обнаружите то, что хороший аналитик бы уже обнаружил, а именно, что вами выделены сущности для действительно важных понятий типа САМОЛЕТА, АВИАЛИНИИ, ЛИЧНОСТИ и т.п. Аналитик бы уже понял, что название авиалинии может быть только атрибутом авиалинии. Если название авиалинии появляется еще где-то в другом месте, то это только потому, что таким образом, видимо, оказалось удобно реализовать связь какого-то объекта с авиалинией; например, название авиалинии может появиться в расписании маршрутов.
Если "роль" члена экипажа на самом деле является "типом роли" с небольшим набором заранее определенных значений (например, командир), с помощью третьей формы нормализации она будет выделена в новую сущность с именем ТИП ЧЛЕНА ЭКИПАЖА.
Также обратите внимание на то, что в окончательной модели появилась новая сущность ЛИЧНОСТЬ, описывающая роль личности в экипаже, назначаемом на РЕЙС. Это нам в дальнейшем пригодится (с точки зрения гибкости), когда между ЛИЧНОСТЬЮ и РЕЙСОМ мы будем добавлять роль ПАССАЖИР, позволяющую членам экипажа быть пассажирами на других рейсах. Модель все еще неточна, поскольку мы не в состоянии уникально определить ЛИЧНОСТЬ, и в ней наблюдается явный недостаток атрибутов, сущностей и связей; тем не менее, мы значительно продвинулись в понимании проблемы.
Рисунок A-2. Третья форма нормализации

Качество атрибутов

"А действительно ли это атрибуты?", то есть описывают ли они, тем или иным образом, данную сущность?
Список проверочных вопросов для атрибута:

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

наименование атрибута не должно включать в себя имя сущности, выполняется ли это условие?

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

отсутствуют ли повторяющиеся значения (или группы)?

описаны ли формат, длина, допустимые значения, алгоритм получения и т.п.?

не может ли этот атрибут быть пропущенной сущностью, которая пригодилась бы для другой прикладной системы (уже существующей или предполагаемой)?

не может ли он быть пропущенной связью?

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

есть ли необходимость в истории изменений?

зависит ли его значение только от данной сущности?

если значение атрибута является обязательным, всегда ли оно известно?

есть ли необходимость в создании домена для этого и ему подобных атрибутов?

зависит ли его значение только от какой-то части уникального идентификатора?

зависит ли его значение от значений некоторых атрибутов, не включенных в уникальный идентификатор?

Качество сущностей

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

является ли имя существительным единственного числа, отражающим суть обозначаемого объекта?

отсутствуют ли пересечения с другими сущностями?

имеются ли хотя бы два атрибута?

всего атрибутов не более восьми, не так ли?

синонимы/омонимы

сущность определена полностью?

объемная информация?

уникальный идентификатор?

имеется ли хотя бы одна связь?

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

распределенные требования?

ведется ли история изменений?

соответствие принципам нормализации данных

нет ли такой же сущности в другой прикладной системе, может быть под другим именем?

не имеет ли она чересчур общий смысл?

достаточен ли уровень обобщения, воплощенный в ней?

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

отсутствуют ли пересечения с другими подтипами?

имеет ли подтип какие-нибудь атрибуты и/или связи?

имеют ли они все свои собственные уникальные идентификаторы или наследуют один на всех от супертипа?

имеем ли мы исчерпывающий набор подтипов?

не следует ли описать "тип" с помощью одного из методов, рассмотренных в Главе 7?

не является ли он лишь примером вхождения сущности?

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

Качество связей

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

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

участвуют ли в ней только две стороны?

проверьте корректность описания с помощью обратного синтаксиса (глава 3)

не является ли связь переносимой?

заданы ли степень связи и обязательность для каждой стороны?

допустима ли конструкция связи? Пример недопустимой конструкции:

(см. Приложение B).

не относится ли ее конструкция к редко используемым (типа "один к одному" или "многие ко многим")?

не является ли она избыточной?

не изменяется ли она с течением времени?

если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону?

Для исключающей связи:

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

все ли из них относятся к одной и той же сущности?

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

связь может покрываться только одной дугой

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

Как показывать модель пользователю

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

Какие же цели преследует МВМС?

Вот они:

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

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

Классификации и категории

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

В данном случае мы использовали простой атрибут. Продукт может быть классифицирован по любому из значений; проверка не производится и каждая классификация подразумевается как взаимно исключающая. Каждый продукт в данный момент может быть классифицирован только одним способом и лицо, проводящее классификацию, должно знать, что она означает.
Рисунок 8-17. Классификация по коду

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

Модель позволяет производить классификацию продуктов по любому количеству признаков. В ней также учтен фактор времени. Обратная связь типа "многие ко многим", отличающая сущность КЛАССИФИКАЦИОННАЯ ГРУППА ПРОДУКТОВ, отражает вложенность классификационных групп.
Следует заметить, что эта связь имеет структуру, подобную структуре "перечня материалов".

Ключевая обязанность

Администрирование данных - это ключевая обязанность. Ею нельзя пренебрегать, если вы заинтересованы в создании качественной, гибкой системы, ориентированной на конечного пользователя.
<>

Ключевые вопросы

Десять ключевых вопросов, на которые следует обратить внимание пользователю, с помощью МВМС пытающемуся составить описание своих информационных запросов:
Ключевые вопросы

Данные, как главный ресурс

Административная поддержка

Использование соглашений

Кратчайшее описание

Независимость данных

Настраиваемые шаблоны

Отношение к делу и качество

Общение

Релевантность

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

Данные, как главный ресурс
В наше время по значимости в успешной жизнедеятельности организации информация сравнима с финансовыми, кадровыми и материальными ресурсами. Прогрессивные компании получают преимущество в своей конкурентной борьбе во многом благодаря контролю над этим жизненно необходимым ресурсом.
Административная поддержка
Для формулирования требований, предъявляемых к информации, следует обратиться к помощи администрации. Какими бы способностями к моделированию вы ни обладали, без административной поддержки добиться успеха вам будет трудно.
Использование соглашений
Строгие соглашения, стандарты и руководящие указания необходимы во все времена, в том числе и в отношении нормализации данных.
Кратчайшее описание
Любое понятие должно быть однозначно определено и отражено в модели вместе со всеми связями его с другими объектами. Для примера обратимся к понятию "Заказ на покупку", которое имеет отношение к отделу, товарам, функциям выдачи санкций (разрешений) и т.п.; другими словами, процесс моделирования строится на принципах, которые действуют в БД.
Независимость данных
Описание информационных запросов не должно зависеть от способа хранения данных или метода доступа к ним, дабы не препятствовать творческому и объективному подходу к самой проблеме и к ее решению (см. Рисунок 1-3).

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

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

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

На практике действует правило 80:20, но благодаря дополнительным нескольким процентам удается решать возникающие проблемы и создавать настраиваемые и гибкие проекты.

Общение

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

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

Релевантность

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

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

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

Математические определения

Для тех, кто интересуется, дадим точные определения из книги К.Дж.Дейта "Введение в системы баз данных" (том 1, 4-я редакция, 1986, Addison-Wesley Publishing Co.,Inc., Reading, Massachusets).
Терминология
Используемая здесь терминология имеет отношение скорее к чисто реляционной теории, чем к МВМС, но общие принципы сохраняют свое действие.
Общее определение
"Отношение R находится в третьей форме нормализации (3NF) тогда и только тогда, когда каждый элемент отношения R включает в себя значение первичного ключа, идентифицирующее некоторую сущность, одно или в сочетании со значениями взаимно независимых атрибутов, некоторым образом описывающих эту сущность".
1NF
"Отношение R находится в первой форме нормализации (1NF) тогда и только тогда, когда все имеющиеся домены содержат только элементарные значения".
2NF
"Отношение R находится во второй форме нормализации (2NF) тогда и только тогда, когда оно находится в 1NF и значение каждого неключевого атрибута полностью определяется значением первичного ключа".
3NF
"Отношение R находится в третьей форме нормализации (3NF) тогда и только тогда, когда оно находится в 2NF и значение каждого неключевого атрибута нетранзитивно определяется значением первичного ключа".
Бойс/Кодд (Boyce/Codd)
"Отношение R находится в форме нормализации по Бойс/Кодду (BCNF) тогда и только тогда, когда каждая детерминанта является возможным ключом".
4NF
"Отношение R находится в четвертой форме нормализации (4NF) тогда и только тогда, когда где бы ни существовала многозначная зависимость (MVD) в R, например A ->-> B, ей бы тут же соответствовала и функциональная зависимость атрибутов R от A. Другими словами, все зависимости (функциональные или многозначные) в R имеют форму K -> X (т.е. функциональная зависимость от возможного ключа K к некоторому атрибуту X). Эквивалентно: R находится в 4NF, если оно находится в BCNF и все многозначные зависимости в R фактически присутствуют в функциональных зависимостях (FD)".
5NF
"Отношение R находится в пятой форме нормализации (5NF) тогда и только тогда, когда каждая объединенная зависимость в R является следствием наличия возможных ключей в R".
Все эти определения подразумевают, что каждый элемент можно уникально идентифицировать значениями набора атрибутов, образующих первичный ключ.

Многие к одному

Рисунок B-1. Обязательность на одном конце с необязательностью на другом

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

Применяется редко. Как A, так и B могут существовать без связи между ними.
Рисунок B-3. Обязательность на обоих концах

Достаточно сильная конструкция, предполагающая, что вхождение сущности B не может быть создано без одновременного создания по меньшей мере одного связанного с ним вхождения сущности A. В нашем примере БИЛЕТ становится таковым только тогда, когда он содержит по меньшей мере один КУПОН; до тех пор это только клочок бумаги.
Рисунок B-4. Необязательность на одном конце с обязательностью на другом

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

Многие ко многим

Рисунок B-8. Необязательность на обоих концах

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

Применяется редко. Такие связи всегда подлежат дальнейшей детализации.
Рисунок B-10. Обязательность на обоих концах

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

Модель для билета с открытой датой вылета

Если вы посмотрите на билет с открытой датой вылета, вы заметите, что отсутствие даты является единственным его отличием от обычного билета. В нем точно так же указывается пассажир и номер рейса. Таким образом, у нас есть билеты, которые связаны с конкретным рейсом (на конкретную дату) или имеют открытую дату на конкретный маршрут. Запомните, что открытым является купон, а не билет, мы несколько нарушили терминологию.
Рисунок 6-3. Использование исключающей дуги для ситуации "либо-либо"

Как и в случае с кредитной карточкой мы используем исключающую связь, изображая ее с помощью дуги. Схема теперь может быть прочитана следующим образом:
Каждый КУПОН должен либо оформляться на один и только один РЕЙС, либо быть открытым для одного и только одного АВИАМАРШРУТА.
Использование подтипов
Рейсы можно разделить на два различных типа:
Рисунок 6-4. Подтипы сущности

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

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

БИЛЕТ

дата выписки

полная стоимость

скидка

денежная единица

принадлежность пассажира к штату

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

Однако, как же мы можем установить принадлежность пассажира к экипажу и рабочую нагрузку члена экипажа?

Нам придется отказаться от понятия "пассажиры". То есть от соответствующей сущности на нашей схеме. Вместо этого уясним себе, что члены экипажа, агенты, командиры, стюардессы и т.п. - все это разные роли или занятия личности, и что личность выступает пассажиром (или потенциальным пассажиром) только в связи с оформлением билета или посадочного талона. Таким образом, понятие "пассажир" исчезает и заменяется на множество связей с сущностью ЛИЧНОСТЬ, как показано на следующей схеме:

Рисунок 6-6. Связи сущности ЛИЧНОСТЬ



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

имеют купоны, но не имеют посадочного талона;

прошли оформление места, но не имеют купонов, а также

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

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

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


Рисунок 6-7. Стандартные экипажи



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

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

1. Для определения состава экипажа мы можем использовать тип самолета.

Каждый ТИП САМОЛЕТА может определять одну и более ДОЛЖНОСТЕЙ В СТАНДАРТНОМ ЭКИПАЖЕ, каждая из которых выполняет определенную РОЛЬ В ЭКИПАЖЕ: например, пять членов экипажа выполняют роль стюарда (стюардессы).

2. Если авиамаршрут предъявляет к членам экипажа особые требования, например при большой продолжительности полета, его следует учитывать наряду с типом самолета.

Реализация этих связей нами уже рассматривалась ранее при разборе состава экипажа.

На следующей схеме вновь появляется сущность НАЗНАЧЕНИЕ В ЭКИПАЖ, благодаря чему схема превращается в модель, отражающую все данные по составлению экипажа.

Рисунок 6-8

Модель кредитной карточки

Рисунок 4-2. Модель взаимосвязей между сущностями для примера с кредитными карточками

Замечания
Проверим, как работает схема в следующих возможных ситуациях. От ЛИЧНОСТИ перейдем ко СЧЕТУ и заявим два экземпляра карточек - один для вас и один для вашей супруги.
То же самое можно сделать со счетом вашей супруги и с карточками для нее, для вас и вашего ребенка.
Начиная путь от КОМПАНИИ, перейдем к СЧЕТАМ, которыми она владеет, с КРЕДИТНЫМИ КАРТОЧКАМИ, выписанными на них, и проверим наличие держателя карточки. Обратите внимание на то, что слово "держатель" используется в описании связи с личностью, выступающей в соответствующей роли.
ТИП КАРТОЧКИ представляет собой самостоятельную сущность, связанную с другой сущностью УСЛОВИЕ по принципу "родитель-потомок". С каждым типом может быть связано много различных условий, поэтому УСЛОВИЕ не может выступать атрибутом ТИПА КАРТОЧКИ, иначе будет нарушено правило, по которому атрибут не может иметь несколько значений одновременно.
От ТИПА КАРТОЧКИ перейдем к КАРТОЧКАМ данного типа и далее к соответствующим СЧЕТАМ, на основании которых выдаются карточки, и к их владельцам. Теперь мы можем определить, сколько карточек различных типов числится на персональных счетах и счетах компаний.
Владельцев счетов отыскать просто, если двигаться по линиям с надписью "принадлежит".
Для полноты сама кредитная компания изображается в виде возможного экземпляра сущности КОМПАНИЯ со связью "СЧЕТ управляется/ КОМПАНИЯ осуществляет кредитование". Такая конструкция позволяет использовать более одной кредитной компании, а также каждой кредитной компании иметь счет для своего собственного персонала.
Связь между ЛИЧНОСТЬЮ и КОМПАНИЕЙ, имеющая тип "многие ко многим", позволяет узнать место работы каждого держателя карточки, не работающего в данной компании.
Обратите внимание на то, что каждый СЧЕТ должен служить основанием для выдачи по меньшей мере одной КРЕДИТНОЙ КАРТОЧКИ. Это явствует из правила, по которому бессмысленно иметь счет без хотя бы одной карточки.
Атрибут "подпись", принадлежащий КРЕДИТНОЙ КАРТОЧКЕ, является необязательным, поскольку между выпуском карточки и моментом ее подписания держателем должно пройти некоторое время.
И, наконец, хотя у ТИПА КАРТОЧКИ уже есть атрибут "лимит", мы добавили "специальный лимит" в качестве атрибута у КАРТОЧКИ, чтобы иметь возможность делать исключения для особых ЛИЧНОСТЕЙ.

Моделирование сущностей

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

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

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

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

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

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

Моделирование взаимосвязей после 3NF

Аналогичные принципы действуют в моделях прикладного уровня; чтобы проверить их выполнение, ответьте на вопросы:
"Действительно ли вы идентифицировали каждую отдельную сущность?"
"Является ли каждая связь действительно существенной или же в ней возникает потребность только в ходе выполнения функции?" "Не может ли атрибут быть на самом деле связью или чем-нибудь еще?"
"Не представляет ли атрибут самостоятельную ценность - с чьей -нибудь точки зрения? (в этом случае из него лучше сделать сущность)"
"Не отражают ли сущности с похожим набором атрибутов и/или связей фактически различные восприятия или состояния одного и того же объекта?"

Назначение

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

Нормализация

Для проверки того, что модель взаимосвязей между сущностями, все сущности которой определены уникально, является полностью нормализованной и таким образом укладывается в правила Третьей формы нормализации, выполним следующие тесты.
Предварительное действие
Убедитесь в том, что все сущности имеют уникальные идентификаторы в виде комбинации атрибутов и/или связей.
Первая форма нормализации
Удалите повторяющиеся атрибуты или группы атрибутов.
Если атрибут имеет в каждый момент времени более одного значения или имеются еще атрибуты с тем же наименованием, мы задаем новую сущность, описываемую этим атрибутом. Уникальный идентификатор для новой сущности включает в себя один из атрибутов, перешедших к ней, и связь ("многие к одному") с первоначальной сущностью.
Пусть нам нужно убрать, например, группы атрибутов для членов экипажа с номерами 1,2,3. Это приведет к созданию новой сущности ЧЛЕН ЭКИПАЖА, имеющей атрибуты "имя" и "роль" и связь типа "многие к одному" с исходной сущностью РЕЙС. (См. путь 1NF на схеме.)
Первая форма нормализации, таким образом, представляет собой механизм обнаружения пропущенных сущностей и связей.
Вторая форма нормализации
Удалите атрибуты, зависящие только от части уникального идентификатора.
Если сущность имеет уникальный идентификатор, состоящий из нескольких атрибутов и/или связей, и если значение какого-нибудь атрибута (не входящего в него) зависит только от какой-то части идентификатора (но не от всего идентификатора целиком), тогда этот атрибут и эта часть (от которой он зависит) должны составить основу новой сущности. Новая сущность идентифицируется перешедшим к ней фрагментом уникального идентификатора исходной сущности и имеет связь с ней типа "один ко многим".
Так, например, значение атрибута "номер рейса" не зависит от даты и времени вылета. Мы получим сущность АВИАМАРШРУТ с фиксированным номером рейса, которому соответствуют один или несколько РЕЙСОВ, совершенных за период времени. (См.
путь 2NF на схеме.)

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

Рисунок A-1. Первая и вторая формы нормализации



Третья форма нормализации

Удалите атрибуты, значения которых зависят от атрибутов, не входящих в уникальный идентификатор.

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

Так, например, название авиалинии, тип самолета и количество мест в самолете не зависят от номера рейса, выполняемого по АВИАМАРШРУТУ. Присвоение авиалинии названия - прерогатива скорее ее президента, а не тех, кто занимается планированием маршрутов и рейсов. (См. путь 3NF на схеме.)

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

О чем мы узнали?

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

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

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

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

О чем мы узнали?

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

исключающая связь

подтип сущности и

непереносимая связь.

Благодаря этому мы получили богатый набор средств, позволяющий моделировать практически любую ситуацию.
Однако, нам необходимо еще до конца разобраться во всем этом, как это было сделано в главе 3 и как это будет сделано в главе 7. Читателю не мешает периодически заглядывать в те приложения, которые касаются нормализации данных, проверки допустимости связей и прикладного аспекта. Можно прочитать все указанные разделы и вновь вернуться к данной главе. (Проверьте модель, создав обзоры для назначения в экипаж и для посадочного талона.)
Но существуют еще и другие разделы. Повторите некоторые темы из МВМС и сведите вместе все вопросы, связанные с построением качественных моделей.
Запомните: качественной моделью взаимосвязей между сущностями является такая, которая обладает полнотой, понятна для пользователей в той же степени, что и для разработчиков, учитывает деловые интересы и реализует все связанные с ними функции. Если такая модель построена, можно смело переходить к проектированию БД и файлов (Приложение F).

О чем мы узнали?

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

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

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

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

Обобщенные модели

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

Общие подходы

На последнем примере мы увидели, что создание более простой и в то же время более универсальной модели основывается на допущении существования у множества сущностей сходных атрибутов и/или связей. Следуя правилам представления объектов на схемах, вы часто будете сталкиваться с тем, что такие сущности имеют тенденцию перемещаться - это поможет вам при выборе структур с более высоким уровнем обобщения.
Шаг 1
Приступим к поиску возможностей для достижения более высокого уровня обобщения:
Рисунок 8-33. Базовая структура

Все три граничные сущности имеют сходные атрибуты (главным образом, даты) и все имеют связь с сущностью ЛИЧНОСТЬ. Если КУРС ОБУЧЕНИЯ и ТИП ЗАНЯТИЯ посчитать к тому же сходными сущностями, то можно перейти к выполнению второго шага.
Шаг 2
Рисунок 8-34. Создание двух обобщающих сущностей-супертипов

Проверим схему.
Учитывает ли она все обстоятельства, охватываемые предыдущей моделью?
Да, мы можем связать:

приложение сил с занятием

обучение с курсом

договор найма с занятием

Что нового появилось? Что дает нам связь:

приложения сил с курсом обучения

обучения с занятием (обучение занятию?)

договора найма с курсом обучения

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

Общие схемы

Представление модели предприятия можно облегчить с помощью упрощенных схем, иллюстрирующих процесс управления в отличие от детальных схем, которые описывают конкретное действие. Существуют две разновидности таких упрощенных схем: схема предметных областей и обзорная схема.
Схема предметных областей
Нижеприведенная схема не является моделью взаимосвязей между сущностями. Это рисунок, на котором блоки представляют концептуально-близкие группировки сущностей, атрибутов и связей. Эти группировки отражают субъективное отнесение тех или иных понятий к конкретной предметной области.
Рисунок 11-1. Схема предметных областей
<>
Линии, соединяющие блоки на рисунке, отражают некоторую форму связи или взаимодействия (интерфейса), существующего между различными предметными областями. (Они не являются "связями" с точки зрения МВМС, но изображаются аналогично, дабы избежать использования новых символов.) Предметная область для ЗАКАЗА БИЛЕТОВ В АВИАКОМПАНИИ может в действительности включать в себя сущности БИЛЕТ, МЕСТО, КЛАСС МЕСТА, ОФОРМЛЕНИЕ МЕСТ, ПОСАДОЧНЫЙ ТАЛОН и любые другие сущности или связи, описывающие предмет.
Руководству нравятся подобные схемы своей простотой и понятностью, ибо в них используются близкие для него термины, часто мелькающие в разговоре.
Аналитикам эти схемы могут предоставить еще одну возможность для проверки качества и полноты модели.
"Располагаем ли мы всей информацией по ПАССАЖИРСКОЙ СЛУЖБЕ?"
Если мы чувствуем неуверенность, мы можем перейти на следующий уровень декомпозиции предметной области и задать вопрос типа:
"Не могли бы вы ввести меня в курс обслуживания пассажиров, дабы я мог убедиться в том, что ничего важного не упустил?"
Обзорная схема
В данном случае рисунок представляет собой упрощенную модель взаимосвязей между сущностями. Он как бы отвечает на вопрос:
"Какие из сущностей по-настоящему важны для нас и чем мы можем пренебречь без ущерба для смысла, заложенного в модели?"
Фактически это означает, что мы должны отбросить некоторые из подтипов, проигнорировать отдельные сущности и связи, убрать все атрибуты (кроме одного-двух) и все уникальные идентификаторы.

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

Упрощая схему, старайтесь в то же время сохранить ее первоначальную форму; это поможет ее легче усвоить.

Удаление подтипов

На рисунках 11-2 и 11-3 показано, как не растеряв связи и не искажая их смысла, можно убрать подтипы из фрагмента модели.

Рисунок 11-2. Модель с подтипами

<>

Рисунок 11-3. Упрощенная модель без подтипов

<>

В примере, приведенном ниже, для таких сущностей, как САМОЛЕТ и РЕЙС, подтипы опущены. Большинство сущностей, имеющих отношение к стандартному экипажу, удалено; из них на этом уровне оставлена только сущность НАЗНАЧЕНИЕ В ЭКИПАЖ. Сущности ОФОРМЛЕНИЕ МЕСТ и ПОСАДОЧНЫЙ ТАЛОН объединены в одну, в результате появилась исключающая дуга, пересекающая связи новой сущности с МЕСТОМ и с САМОЛЕТОМ.

Рисунок 11-4. Обзорная схема

<>

Один к одному

Рисунок B-5. Обязательность на одном конце с необязательностью на другом

Используется редко.
Рисунок B-6. Необязательность на обоих концах

Используется редко.
Рисунок B-7. Обязательность на обоих концах

Крайне редко (почти всегда ошибочно).
При ближайшем рассмотрении связи типа "один к одному" почти всегда оказывается, что A и B представляют собой в действительности разные подмножества одного и того же предмета или разные точки зрения на него, просто имеющие отличные имена и по-разному описанные связи и атрибуты. Некоторые из аналитиков используют связи типа "один к одному" для включения в модель пересекающихся или ортогональных подтипов. (См. Главу 7.)

Определение атрибута

Полное определение атрибута подразумевает указание для него следующих параметров (см. форму C9):

		Этап стратегии		Этап анализа		Правила
Наименование		Н		Н		Не играет существенной роли, но может пригодиться. Лаконичность ускоряет перекрестные ссылки.
Описание		Н		О
Обязательный/необязательный		Н		О
% первоначально		Н		Н		Только для необязательных атрибутов.
% обычно		Н		Н		Только для необязательных атрибутов. Используется для разработки и настройки механизма хранения.
При условии		Н		Н		Только для необязательных атрибутов. Определяет условия, при которых значение должно существовать.
Формат		Н		О		Character, integer, date,...
Максимальная длина		Н		О
Средняя длина		Н		Н
Единица измерения		Н		Н
Доступность для пользователя		Н		Н		Иногда такие домены, как например "оклад", ограничивают доступ к входящим в них атрибутам. Но это бывает нечасто.

		Этап стратегии		Этап анализа		Правила
Права доступа		Н		Н		Имеются в виду права на создание значения (C), коррекцию (U), удаление (D), помещение в архив (A), выборку/чтение (R)
Уровень полномочий		Н		Н		Уровень доступа к данным может регулироваться уровнем полномочий.
Объект ответственности		Н		Н		Домены, реализующие внутренние правила организации, могут быть предметом заботы и ответственности конкретного пользователя.
Правило допустимости значений		Н		Н		Алгоритм или список значений (см. ниже).
Значение по умолчанию		Н		Н		Используется крайне редко (только когда атрибут обязательный).
Если null		Н		Н		В некоторых реализациях null предполагает "отсутствие текущего значения". Если вам нужна иная трактовка, вам следует заранее договориться с пользователем о том, какое конкретное значение использовать в этом случае. Для необязательных атрибутов. (См. Глоссарий.)
Происхождение		Н		Н		Вычисление, подсчет или алгоритм (редко).
Набор значений или диапазоны: значение		Н		Н		Точное значение (или нижняя граница диапазона).
наивысшее значение		Н		Н

<

	Этап стратегии	Этап анализа	Правила
аббревиатура	Н	Н	Согласована с пользователем.
суть	Н	Н	Полный смысл значения или диапазона.

Взаимоотношения с другими элементами

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

Обозначения:

О - обязательный параметр Н - необязательный параметр

Определение домена

Полное определение домена подразумевает указание для него следующих параметров (см. форму C3):

		Этап стратегии		Этап анализа		Правила
Наименование		Н		Н		Лаконичность ускоряет перекрестные ссылки.
Описание		Н		О
Формат		Н		О		Character, integer, date,...
Максимальная длина		Н		О
Средняя длина		Н		Н
Единица измерения		Н		Н
Доступность для пользователя		Н		Н		Иногда такие домены, как например "оклад", ограничивают доступ к входящим в них атрибутам. Но это бывает нечасто.
Права доступа		Н		Н		Имеются в виду права на создание значения (C), коррекцию (U), удаление (D), помещение в архив (A), выборку/чтение (R)
Уровень полномочий		Н		Н		Уровень доступа к данным может регулироваться уровнем полномочий.
Объект ответственности		Н		Н		Домены, реализующие внутренние правила организации, могут быть предметом заботы и ответственности конкретного пользователя.
Правило допустимости значений		Н		Н		Алгоритм или список значений (см. ниже).
Значение по умолчанию		Н		Н		Используется крайне редко.

		Этап стратегии		Этап анализа		Правила
Если null		Н		Н		В некоторых реализациях null предполагает "отсутствие текущего значения". Если вам нужна иная трактовка, вам следует заранее договориться с пользователем о том, какое конкретное значение использовать в этом случае (см. Глоссарий).
Происхождение		Н		Н
Набор значений или диапазоны: значение		Н		Н		Точное значение (или нижняя граница диапазона).
наивысшее значение		Н		Н
аббревиатура		Н		Н		Согласована с пользователем.
суть		Н		Н		Полный смысл значения или диапазона.

Взаимоотношения с другими элементами

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

<

Обозначения:

О - обязательный параметр Н - необязательный параметр

ПОЛНОЕ ОПРЕДЕЛЕНИЕ АТРИБУТА

Код 215 ORACLE (R)

Система управления реляционной базой данных Наименование статус..... Сущность КУПОН..... Домен.....

Описания/замечания Определяет состояние купона с точки зрения его анализа

Обязательный/необязательный .....% первоначально .....% обычно при условии .....

Формат Макс. длина Средняя Единица измерения char 1 ..... ..... Пользователь Права доступа (C,U,D,A,R,Все) Уровень полномочий доступен для ..... ..... ..... Объект ответственности ..... ..... ..... Правило допустимости значений Допускаются следующие переходы из одного состояния в другое Из В 1 2,3,6,7,9 2 3,6,9 Значение по умолчанию .......... (только если обязательное) если null .......... (только если необязательное) Происхождение При создании купона статус=1 Значение Наивысшее значение Аббревиатура Суть 1 Создан 2 Собран или выдан 3 Использован обычно 6 Перенесен или заменен 7 Продан за деньги 9 Недействителен

Форма	Группа	Проект	Аналитик	Дата	Лист...
C9	Пользователь	Действие	Проверил	Дата	Всего...

Определение сущности

Полное определение сущности подразумевает указание параметров, перечисленных в стандартных формах C6 и C7 и требуемых для работы в среде CASE. Если подразделения организации разбросаны географически, требования распределенной обработки должны быть зафиксированы в форме C8 (дополняющей форму C6).
В форме "Определение сущности" для каждого атрибута вы можете указать наименование, обязательность, домен, формат, замечания и принадлежность к уникальному идентификатору. Для большинства атрибутов этого достаточно. Для более детального описания атрибутов используется форма C9 (где приводятся те же сведения, но с дополнительными подробностями).
Параметры сущности

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

Обозначения:

О - обязательный параметр Н - необязательный параметр

Взаимоотношения сущности с другими элементами

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

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

Обеспечение целостности

Правила

Н

Н

В некоторых случаях имеют решающее значение, если отражают существенные (а не случайные) для предмета правила. Указываются в форме C7 или C8.

Обозначения:

О - обязательный параметр Н - необязательный параметр

Объемные характеристики

	Этап стратегии	Этап анализа	Правила
Объемы	Н	О	Может быть просто одно значение (например, 200 самолетов), тогда укажите начальный, средний и максимальный объемы и темп роста, используя форму C6. Если нужно указать диапазоны, темпы роста по периодам и распределение внутри организации, используйте форму C7. Объемы подтипов должны примерно совпадать с объемами супертипов.
Архивирование	Н	Н	Страхует от краха системы. Указывается в формах C7 или C8 для всех объемных сущностей

Обозначения:

О - обязательный параметр Н - необязательный параметр

Определение связи

Полное определение связи подразумевает указание для каждого из ее концов следующих параметров (см. форму C6):
Параметры связи

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

Признак каскадного удаления

Признак каскадного удаления

Н

Н

X = Каскадное удаление в случае удаления родителя. C = Родитель не удаляется, пока существует хоть один потомок. N = Родитель и потомок могут удаляться отдельно друг от друга.

Обозначения:

О - обязательный параметр Н - необязательный параметр

Взаимоотношения с другими элементами

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

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

		Этап стратегии		Этап анализа		Правила
Уникальный идентификатор		Н		Н		Каждый конец связи может быть компонентой одного или нескольких уникальных идентификаторов.

<

Обозначения:

О - обязательный параметр Н - необязательный параметр

Наиболее употребительные описания связей

До тех пор, пока вы не наберетесь собственного опыта, вы можете сэкономить время, используя предлагаемые ниже примеры описания связей:

Пары описаний связи

о (about)	предмет (subject of)
в отношении к (applicable to)	контекст для (context for *)
в (at)	место для (location of)
основано на (based on)	основа для (basis for)
получено от (bought in from)	поставщик (supplier of)
основание для классификации (classification for)	имеет (of)
покрывается (covered by)	для (for)
определяется (defined by)	частично определяет (part definition of)
описание (description of)	характеризуется (for)
для (for)	отражается на (shown on)
для работы под (for work under)	основание для (authority for)
инициализируется (initiated by)	инициатор (initiator of)
кандидат на (nominee for)	объект притязаний (subject of)
упоминается на (notified on)	место упоминания (notification point for)
управляется (operated by)	приводит в действие (operator for)
принадлежит (owned by)	владелец (owner of *)
составная часть (part of)	состоит из (composed of)
часть (part of)	детализируется на (detailed by)
участвует в (party to)	для (for)
представляется (represented by)	представление для (representation of)
несет ответственность за (responsible for)	объект ответственности (responsibility of)
обслуживается (run by)	курирует (carrier for)
источник для (source of)	строится на (based on)
вызывает (trigger for)	приводится в действие (triggered by)
при (under)	контекст для (context for)
в пределах ответственности (within)	отвечает за (responsible for)

Примечание:

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


Некоторые из примеров отражают ту или иную роль личности или организации.

ОПРЕДЕЛЕНИЕ ДОМЕНА (ПРИКЛАДНОЙ УРОВЕНЬ)

Код 173 ORACLE (R)

Система управления реляционной базой данных Наименование домена КЛАСС Подмножество домена

Описания/замечания Определяет допустимые значения классификации воздушных перелетов, имеющие отношение к КУПОНАМ и МЕСТАМ Формат Макс. длина Средняя Единица измерения char 8 7 Пользователь Права доступа (C,U,D,A,R,Все) Уровень полномочий доступен для ..... ..... ..... Объект ответственности ..... ..... ..... Правило допустимости значений Значение по умолчанию если null Экономический ..... Происхождение Значение Наивысшее значение Аббревиатура Суть Бизнес В Деловой или высший класс Экономический Е Экономический или второй класс Первый F Первый класс

Форма	Группа	Проект	Аналитик	Дата	Лист 1
C3	Пользователь	Действие	Проверил	Дата	Всего 1

Перечень материалов

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

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

какие продукты выпускаются и их состав

В этих случаях говорят о типах компонент и продуктов. Компонента одного и того же типа (например, мотор) может входить в состав множества других компонент или продуктов. Изобразим это утверждение в виде схемы.
Рисунок 8-14.

Возможностей этой модели нам окажется недостаточно, если нас будет интересовать количественный аспект и порядок сборки. Для этого нам понадобится создать граничную сущность с подобными атрибутами (как мы это делаем, когда сталкиваемся со связью типа "многие ко многим").
Рисунок 8-15. Создание граничной сущности, разрывающей связь "многие ко многим"

Разложение на части
Каждая КОМПОНЕНТА или ПРОДУКТ может состоять из одной и более СТАНДАРТНЫХ СОСТАВЛЯЮЩИХ соответствующего количества и порядка сборки, каждая из которых должна отражать назначение той или иной КОМПОНЕНТЫ или ПРОДУКТА.
И наоборот, каждая КОМПОНЕНТА или ПРОДУКТ может использоваться в качестве одной и более СТАНДАРТНЫХ СОСТАВЛЯЮЩИХ, каждая из которых должна входить в список компонент для другой КОМПОНЕНТЫ или ПРОДУКТА.
С терминологией могут возникнуть трудности. Вы должны прежде всего признать то, что форма правильна, а терминологию вы можете использовать ту, которая предполагается соглашениями, принятыми в исследуемой организации. От организации к организации слова, обозначающие одно и то же, меняют свое написание:

часть

компонента

составляющая

продукт

список ингредиентов

оборудование

установка

и многие другие.

Пользовательское одобрение

Регулярно представляйте вашу модель или ее отдельные фрагменты, относительно которых у вас возникают сомнения, на одобрение пользователей. Поддерживайте в них желание работать с вами бок о бок над поиском и исправлением ваших ошибок и упущений. Особое внимание уделяйте исключениям из правил и ограничениям. Разобравшись в проблеме на 100%, разработчики смогут создать такой проект БД, который будет учитывать до 82% запросов, действительно нуждающихся в компьютерной поддержке (обычно действует правило 80:20; дополнительные 2% позволяют существенно снизить издержки по сопровождению).

Поток и хранилище данных

Многие аналитики и проектировщики пользуются понятием "схема потоков данных", подразумевающим отражение взаимосвязей между управленческими функциями, принимающими или передающими данные. Пример см. на следующей странице.
Рисунок 9-1. Схема потоков данных для функции "Поставка и сопровождение"

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

Правила для атрибутов

Следующие несложные правила позволяют создавать точные, полные и гибкие модели. См. также Приложение A.
Атрибут служит для описания одной сущности
Атрибут должен определять именно ту сущность, под которой он подписан.
Это может показаться очевидным, однако наиболее часто возникающие ошибки связаны с атрибутами. Так, например, "номер места" является атрибутом купона, билета, посадочного талона, самолета или места в самолете? Очевидно, это атрибут МЕСТА, однако в реальной жизни этот номер зачастую многократно дублируется, появляясь, например, в том числе и на посадочном талоне, включенном в схему в качестве сущности (Рисунок 3-12).
Почему так? В реальном мире номер места очень удобно использовать для представления связи. Если вам известны подобные случаи, добавьте в схему линии таких связей (при необходимости, создавая недостающие сущности).
Рисунок 3-12. Передача атрибута "истинному владельцу"

Как правило, для описания большинства сущностей используется от двух до восьми атрибутов. Превышение этого числа может быть следствием слишком большого количества связей и/или отсутствия некоторых необходимых сущностей.
Чтение названий атрибутов
В названии атрибута не следует использовать имя сущности. Это будет излишним, ибо атрибут описывает только одну сущность. В вышеприведенном примере "номер места" в действительности идентифицировал отсутствующую сущность МЕСТО, которая кроме атрибута "номер" может иметь и другие атрибуты, например "тип".
Чтобы прочитать атрибуты, названные таким образом, вы можете воспользоваться одной из следующих двух форм:
Имя сущности Название атрибута или Название атрибута Имя сущности , например: номер места.
В классическом примере со служащими и отделами "номер отдела" не является атрибутом сущности СЛУЖАЩИЙ. Он выступает атрибутом сущности ОТДЕЛ.
Убирайте повторяющиеся атрибуты
В одно и то же время сущность не может иметь более одного значения каждого из ее атрибутов. Если значений атрибута оказывается много, вам нужно создать новую сущность с передачей ей этого атрибута и с установлением связи типа "многие к одному" с первой сущностью.
Воспользуемся старым примером:

Рисунок 3-13. Повторяющийся атрибут указывает на отсутствие сущности



Следуя указанному правилу, мы получим:

Рисунок 3-14. Добавление недостающей сущности



Это правило часто называют "Первой формой нормализации" (см. Приложение A).

Использование единственного числа в наименованиях

Название атрибута должно быть дано в единственном числе. Множественное число часто является отражением проблемы повторяющихся атрибутов. Для сущности САМОЛЕТ такими атрибутами могут стать - места, экипаж, двери и двигатели. Еще раз обратите внимание на отсутствие на схеме тех сущностей, которым могут принадлежать эти атрибуты.

Может это сущность?

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

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

Рисунок 3-15. Атрибут может стать сущностью



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

Рисунок 3-16

Правила для сущностей

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

Правила размещения объектов на схемах

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

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

Рисунок 3-22



Степень связи

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

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

Размер и форма блоков

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

Рисунок 3-23. Стандартный вид схемы



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

Качество

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

Дополнительные соглашения

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

Правила

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

Информация должна рассматриваться не только

Информация должна рассматриваться не только как некая принадлежащая предприятию ценность, но и как исходная точка для построения информационной системы, обслуживающей предприятие. На практике во многих организациях пришли к убеждению, что правильное понимание информационного аспекта служит необходимой предпосылкой для построения высококачественных и целостных информационных систем. По этой причине ведущим направлением в разработке программных средств АСУ является переход от процедурно-ориентированных методов разработки к информационно-ориентированным. Информационное проектирование становится самой популярной методологией, пронизывающей все стадии жизненного цикла системы.
Информационное проектирование зачастую характеризуется как подход к созданию систем, сконцентрированный на информации. Это также всеобъемлющая стратегия, основанная на информационном планировании и уяснении целей системы. Главная посылка, на которой строится данная стратегия, состоит в том, что целостность информационных систем определяется степенью охвата информационных элементов объекта соответствующей логической моделью.
Информационное проектирование предполагает прежде всего глубокое исследование всех информационных систем, преследующее своей целью поиск ответа на вопрос: каким образом информация используется и разделяется системами. Программные структуры выступают по отношению к информационной модели уже "надстройкой", определяющей общую информационную инфраструктуру для создания соответствующих систем на предприятии. Таким образом, процедуры логически вытекают из данных, а качество информационных систем определяется качеством построения информационной модели.
Информационное обследование организации - трудоемкая и продолжительная работа. Только опытным аналитикам, вооруженным мощным инструментарием и технологией, под силу обеспечить точность и целостность описания информации.
Моделирование взаимосвязей между сущностями (объектами) представляет собой метод информационного проектирования, предназначенный для построения высококачественной информационной модели.
Информационное моделирование служит стандартным средством определения данных и взаимосвязей между ними, применяемым во всех информационных системах. Оно существенно повышает качество системы и продуктивность программного обеспечения.
Моделирование взаимосвязей становится универсальным методом информационного моделирования. По существу, каждому системному аналитику следует изучать и использовать основы моделирования взаимосвязей между объектами. Существует несколько курсов и пособий, помогающих освоить указанный метод моделирования. Настоящая книга написана Ричардом Баркером, опытным аналитиком, внесшим свой вклад в его развитие и испытание за двадцать лет работы над различными проектами. Изложение основ моделирования в книге сопровождается разъяснением соответствующей терминологии и некоторыми руководящими указаниями. Автор использует примеры из реальной жизни - простые и более сложные - дабы с их помощью облегчить освоение нового метода. Объясняется механизм поддержки метода с помощью CASE-инструментария. В дальнейшем, после освоения метода, пользователь может обращаться к книге как к справочнику, содержащему определение основных понятий и терминов.
Карма Макклар
Сентябрь 1989

Предостережение

Довольно легко перейти грань, отделяющую реальную модель от чересчур обобщенной; в качестве примера последней можно привести модель, называемую "жизнь, вселенная и все, что можно представить":
Рисунок 8-35. Последняя стадия обобщения

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

Претензии пользователей

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

Прикладные функции

Из вышеизложенного следует, что определения функциям следует давать в терминах проблемных представлений. Простые функции реализуются на одном проблемном представлении, часто это представление граничной сущности; например: КУПОН к билету на рейс. Другие функции используют два и более проблемных представлений, связанные между собой ссылками на идентичные производные атрибуты.
Все атрибуты проблемного представления могут использоваться в определении прикладной функции через условия, фразы "where" (где) или другие средства идентификации интересующих нас вхождений.
Вообще говоря, только атрибут текущей сущности может быть объектом корректирующих действий.
Единственное исключение имеет место, когда эти действия производятся в отношении значений атрибутов, корреспондирующих с уникальным идентификатором сущности, непосредственно связанной с текущей. В этом случае можно говорить о попытке изменить связь.
Так, например, если обратиться к проблемному представлению для сущности КУПОН, то можно сказать, что попытка изменения номера рейса и даты отправления будет попыткой изменить связь КУПОНА с РЕЙСОМ (переоформление на другой рейс).
Если функция имеет отношение к РЕГУЛЯРНОМУ РЕЙСУ, атрибуты соответствующего проблемного представления будут использоваться следующим образом:
Рисунок G-5. Проблемное представление РЕГУЛЯРНЫЙ РЕЙС

B. ДОПУСТИМЫЕ ВИДЫ СВЯЗЕЙ

Информация об общепринятых способах описания степени мощности и обязательности связей может оказаться вам полезной.

C. ДЕТАЛИЗИРОВАННЫЕ ОПИСАНИЯ СУЩНОСТИ, СВЯЗИ, ДОМЕНА И АТРИБУТА

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

C6		Определение сущности		(с перечислением атрибутов, связей, уникальных идентификаторов и основных объемов)
C7		Объемные характеристики сущностей		(общие объемы)
C8		Объемные характеристики сущностей		(распределенные требования)
C3		Определение домена
C9		Полное определение атрибута.

Все эти формы взяты из книги "CASE*Method Tasks and Deliverables" (Приложение C) и могут быть размножены для использования при работе с CASE-методом.
                                                           Код 52     ORACLE (R) --------------------- ОПРЕДЕЛЕНИЕ СУЩНОСТИ ----------¬    ¦   Система управления реляционной                               ¦    ¦   базой данных                                                 ¦    ¦                                                                ¦    ¦ Имя                                                            ¦    ¦ (множественная форма) КУПОН(ы).........   Супертип............ ¦    ¦ Синонимы ................. Начальный объем ......              ¦    ¦          ................. Средний объем....... Вероятный      ¦    ¦          .................                      максимум ..... ¦    ¦          ................. Темп роста ......... % в год        ¦    +----------------------------------------------------------------+    ¦ Описание: имеет значение составной части билета, оформляемой на¦    ¦ конкретный рейс через процедуру выписки посадочного талона.    ¦    ¦                                                                ¦    +----------------------------------------------------------------+    ¦ Атрибуты                                                       ¦    ¦   Наименование  Не-     Домен  Формат  Макс.  Заме-  См.   Уни-¦    ¦                 обяза-                 длина  чания  пол-  каль¦    ¦                 тель-                                ное   ный ¦    ¦                 ность                                опи-  ид.
¦    ¦                                                      сание     ¦    +-----------------T---T--------T-------T-------T------T-----T-T--+    ¦ класс           ¦ N ¦ класс  ¦       ¦       ¦      ¦     ¦    ¦    ¦ статус          ¦   ¦        ¦       ¦       ¦      ¦  v  ¦ ¦  ¦    ¦ индикатор под-  ¦   ¦        ¦       ¦       ¦Булево¦     ¦    ¦    ¦ тверждения      ¦ N ¦        ¦ char  ¦   1   ¦знач-е¦     ¦ ¦  ¦    ¦ комментарии     ¦ Y ¦        ¦ char  ¦  40   ¦      ¦     ¦    ¦    ¦                 ¦   ¦        ¦       ¦       ¦      ¦     ¦ ¦  ¦    ¦                 ¦   ¦        ¦       ¦       ¦      ¦     ¦    ¦    +-----------------+---+--------+-------+-------+------+-----+-+--+    ¦ Связи: Каждое вхождение данной сущности                        ¦    ¦ должно/¦связующая¦одну и только одну/¦имя     ¦кас- ¦дуга¦     ¦    ¦ может  ¦фраза    ¦одну и более       ¦сущности¦кад- ¦    ¦     ¦    ¦        ¦         ¦                   ¦        ¦ное  ¦    ¦     ¦    ¦        ¦         ¦                   ¦        ¦уда- ¦    ¦     ¦    ¦        ¦         ¦                   ¦        ¦ление¦    ¦     ¦    +--------+---------+-------------------+--------+-----+----+--T--+    ¦ должно ¦входить в¦один и только один ¦билет   ¦  x  ¦    ¦v  v ¦    ¦ должно ¦оформ-   ¦один и только один ¦рейс    ¦     ¦ 1  ¦v ¦  ¦    ¦        ¦ляться на¦                   ¦        ¦     ¦    ¦     ¦    ¦ должно ¦быть от- ¦один и только один ¦авиа-   ¦     ¦ 1  ¦  ¦v ¦    ¦        ¦крытым на¦                   ¦маршрут ¦     ¦    ¦     ¦    ¦        ¦         ¦                   ¦        ¦     ¦    ¦  ¦  ¦    ¦        ¦         ¦                   ¦        ¦     ¦    ¦     ¦    +--------+---------+-------------------+--------+-----+----+--+--+    ¦ Замечания:                                                     ¦    ¦                                                                ¦    ¦ Полное описание атрибута должно быть введено для всех допусти- ¦    ¦ мых значений атрибута, имеющего "галочку" в столбце "См.


полное¦    ¦ описание".                                                     ¦    ¦                                                                ¦    ¦                                                                ¦    ¦                                 Подробности на следующем листе ¦    L-----------------------------------------------------------------

ОПРЕДЕЛЕНИЕ СУЩНОСТИ

Код 52 ORACLE (R)

Система управления реляционной базой данных
Имя (множественная форма) КУПОН(ы) ..........							Супертип ..........
Синонимы ......... ......... ......... .........				Начальный объем .......... Средний объем .......... Темп роста ..........			Вероятный максимум % в год ..........
Описание: имеет значение составной части билета, оформляемой на конкретный рейс через процедуру выписки посадочного талона.
Атрибуты Наименование		Необя- затель- ность	Домен	Формат	Макс. длина	Замечания	См. полное описание	Уникальный ид.
класс		N	класс
статус							v
индикатор подтверждения		N		char	1	Булево значение
комментарии		Y		char	40
Связи: Каждое вхождение данной сущности
должно/может	связующая фраза	одну и только одну/одну и более			имя сущности	каскадное удаление	дуга
должно	входит в	один и только один			билет	х		v	v
должно	оформляться на	один и только один			рейс		1	v
должно	быть открытым на	один и только один			авиамаршрут		1		v
Замечания: Полное описание атрибута должно быть введено для всех допустимых значений атрибута, имеющего "галочку" в столбце "См. полное описание". Подробности на следующем листе

<

Форма	Группа	Проект	Аналитик	Дата	Лист 1
C6	Пользователь	Действие	Проверил	Дата	Всего 3

ОБЪЕМНЫЕ ХАРАКТЕРИСТИКИ СУЩНОСТИ

Код 52 ORACLE (R)

Система управления реляционной базой данных (общие объемы) Имя сущности КУПОН.......................... (См. распределенные требования) Детализированные объемные характеристики (некоторых сущностей) Объем или % роста Примечания Текущие объемы За: Период 1 Период 2 Период 3 Период 4 Период 5 Архивирование Число Период Причина Сохранять после Удалять после NB. Обеспечьте включение в модель функций сохранения и удаления сущностей с соответствующими условиями их выполнения. Обеспечение целостности Условие Правило При создании купона или его оформлении на рейс Купоны могут оформляться только на рейсы, имеющие в качестве даты отправления вчерашнее число, сегодняшнее число или любое последующее. Вчерашнее число допускается для отложенных рейсов.

Форма	Группа	Проект	Аналитик	Дата	Лист 2
C7	Пользователь	Действие	Проверил	Дата	Всего 3

ОБЪЕМНЫЕ ХАРАКТЕРИСТИКИ СУЩНОСТИ

Код 52 ORACLE (R)

Система управления реляционной базой данных (распределенные требования) Имя сущности КУПОН..........................

ФУНКЦИОНАЛЬНЫЙ БЛОК Обозначение BU-1 Наименование Atlantia Из имеющихся Начальный объем ..... Средний объем ..... Темп роста .....% в год Новый Вероятный максимум ..... Детализированные объемные характеристики (некоторых сущностей) Объем или % роста Примечания Текущие объемы 250.000 ---- За: Период 1 1989 10 % Период 2 1990 30 % Планируемое появление новых авиамаршрутов Период 3 1991 20 % Период 4 Период 5 < Архивирование Число Период Причина Сохранять после 3 месяцев Удалять после 9 месяцев NB. Обеспечьте включение в модель функций сохранения и удаления сущностей с соответствующими условиями их выполнения. Обеспечение целостности Условие Правило

Форма	Группа	Проект	Аналитик	Дата	Лист 3
C8	Пользователь	Действие	Проверил	Дата	Всего 3

D. ИСПОЛЬЗОВАНИЕ CASE-ИНСТРУМЕНТАРИЯ

Поставкой средств автоматизированного проектирования систем или программного обеспечения (CASE) занимаются многие фирмы. Большинство этих средств включают в себя возможность МВМС или др. информационного моделирования. Содержащиеся в данном приложении обзорные схемы дают представление о функциях, выполняемых этими средствами на различных этапах проектирования систем. Этапы выработки стратегии и анализа иллюстрируются более подробно, так как они отражают очередность применения средств, поддерживающих МВМС.
Из схем однако не видны задачи, стоящие на каждом из этапов; они рассматриваются в книге "CASE*Method - Tasks and Deliverables", принадлежащей перу того же автора.

Этап выработки стратегии

F. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ БАЗЫ ДАННЫХ

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

I. ПОЛНАЯ МОДЕЛЬ ДЛЯ АВИАЛИНИИ "ATLANTIS ISLAND FLIGHTS"

Данное приложение содержит модель взаимосвязей между сущностями для авиалинии "Atlantis Island Flights", построенную средствами CASE*Designer в среде Oracle. Поскольку авиалиния - всего лишь гипотетическая, модель нельзя считать не только окончательной, но и даже свободной от упущений и достаточно близкой к реальности. Стоит потратить время на то, чтобы проверить детали, не освещенные в комментариях и замечаниях, и открыть для себя что-то новое в результате таких исследований.
В данном приложении также приведены отчеты CASE*Dictionary для следующих сущностей: БИЛЕТ,КУПОН,АВИАМАРШРУТ,НАЗНАЧЕНИЕ В ЭКИПАЖ.
Также показан пример экрана программы-построителя схем взаимосвязей между сущностями, входящей в состав CASE*Designer'а.
Пример экрана построителя схем взаимосвязей между сущностями
Построители схем взаимосвязей между сущностями включаются в большинство пакетов CASE. Рассматриваемый здесь взят из CASE*Designer'а - многооконного и многопользовательского продукта корпорации Oracle.
В процессе работы с этим средством вы можете выбирать сущности, задавать размеры их блоков, перемещать их и включать в другие сущности (т.е. создавать подтипы), а также выбирать оптимальную форму размещения объектов на схеме. Опции меню позволяют добавлять атрибуты, формировать проект БД по умолчанию, а также многое другое, что может потребоваться на этапах выработки стратегии, анализа и проектирования БД. Похожими возможностями обладают построители матриц, схем информационных потоков, функциональной иерархии и т.п.
         ------------------------------------------------------------¬       -+----------------------------------------------------------¬¦      -+----------------------------------------------------------¬¦¦     -+----------------------------------------------------------¬¦¦¦    -+----------------------------------------------------------¬¦¦¦¦    ¦ Date: 01-AUG-89     ORACLE: CASE*Dictionary      Page:  1 ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦               DETAILED ENTITY DEFINITION                  ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ Entity Name: TICKET                  Application:    ATBS ¦¦¦¦¦    ¦                                      Version    :       1 ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ Sub-type of:                         Reference  :  TICKET ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ Synonyms   : GROUP TICKET         Initial Volume:         ¦¦¦¦¦    ¦                                   Average Volume:   60000 ¦¦¦¦¦    ¦                                   Maximum Volume:         ¦¦¦¦¦    ¦                                   Annual Growth%:      15 ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ --- DESCRIPTION - HAS SIGNIFICANCE AS ------------------- ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ A means of acquiring the right to fly with an airline as  ¦¦¦¦¦    ¦ a passenger.                                              ¦¦¦¦¦    ¦ #                                                         ¦¦¦¦¦    ¦ A contractual document between an airline and a person,   ¦¦¦¦¦    ¦ which may be exchanged, cashed in, or its constituent cou-¦¦¦¦¦    ¦ pons exchanged for a journey with this or another airline.¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ --- ATTRIBUTES ------------------------------------------ ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ Name : CURRENCY                      Domain : CHAR CODE   ¦¦¦¦¦    ¦        Opt : N     Format : CHAR     Length : 3           ¦¦¦¦¦    ¦ Name : DATE OF ISSUE                 Domain :             ¦¦¦¦¦    ¦        Opt : N     Format : DATE     Length :             ¦¦¦¦¦    ¦ Name : DISCOUNT GIVEN                Domain :             ¦¦¦¦¦    ¦        Opt : N     Format : MONEY    Length : 6.2         ¦¦¦¦¦    ¦ Name : FULL FARE                     Domain :             ¦¦¦¦¦    ¦        Opt : N     Format : MONEY    Length : 6.2         ¦¦¦¦¦    ¦ Name : NUMBER                        Domain :             ¦¦¦¦¦    ¦        Opt : N     Format : INTEGER  Length : 9         * ¦¦¦¦¦    ¦ Name : STAFF INDICATOR               Domain :             ¦¦¦¦¦    ¦        Opt : N     Format : CHAR     Length : 1           ¦¦¦¦¦    ¦ Name : TIME OF ISSUE                 Domain :             ¦¦¦¦¦    ¦        Opt : N     Format : TIME     Length :             ¦¦¦¦¦    ¦               * - Attributes in primary unique identifier ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ --- RELATIONSHIPS --------------------------------------- ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ EACH OCCURRENCE OF THIS ENTITY :                          ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ MUST BE made up of     ONE OR MORE     COUPONS            ¦¦¦¦¦    ¦ MUST BE issued by    ONE AND ONLY ONE  ORGANIZATION UNIT  ¦¦¦¦¦    ¦ MUST BE for          ONE AND ONLY ONE  PERSON             ¦¦¦+-    ¦            * - Relationships in primary unique identifier ¦¦+-    ¦                                                           ¦+-    ¦ --- NOTES AND REMARKS ----------------------------------- +-    L------------------------------------------------------------                   ------------------------------------------------------------¬       -+----------------------------------------------------------¬¦      -+----------------------------------------------------------¬¦¦     -+----------------------------------------------------------¬¦¦¦    -+----------------------------------------------------------¬¦¦¦¦    ¦ Дата: 01-AUG-89     ORACLE: CASE*Dictionary      Стр.:  1 ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦            ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ          ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ Имя сущности: БИЛЕТ           Прикладная система:    ATBS ¦¦¦¦¦    ¦                               Версия            :       1 ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ Супертип    :                 Ссылка            :   БИЛЕТ ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ Синонимы    : ГРУППОВОЙ БИЛЕТ   Начальный объем :         ¦¦¦¦¦    ¦                                 Средний объем   :   60000 ¦¦¦¦¦    ¦                                 Максимальн.объем:         ¦¦¦¦¦    ¦                                 Годовой прирост%:      15 ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ --- ОПИСАНИЕ - ИМЕЕТ ЗНАЧЕНИЕ --------------------------- ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ Средства приобретения права на полет, курируемый авиалини-¦¦¦¦¦    ¦ ей, в качестве пассажира.                                 ¦¦¦¦¦    ¦ #                                                         ¦¦¦¦¦    ¦ Договора между авиалинией и личностью, допускающего изме- ¦¦¦¦¦    ¦ нения и перепродажу, о путешествии по маршруту, курируемо-¦¦¦¦¦    ¦ му этой или другой авиалинией.                            ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ --- АТРИБУТЫ -------------------------------------------- ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ Имя  : ВИД ВАЛЮТЫ                     Домен : CHAR CODE   ¦¦¦¦¦    ¦  Необязательн.: N    Формат : CHAR    Длина : 3           ¦¦¦¦¦    ¦ Имя  : ДАТА ВЫПИСКИ                   Домен :             ¦¦¦¦¦    ¦  Необязательн.: N    Формат : DATE    Длина :             ¦¦¦¦¦    ¦ Имя  : СКИДКА                         Домен :             ¦¦¦¦¦    ¦  Необязательн.: N    Формат : MONEY   Длина : 6.2         ¦¦¦¦¦    ¦ Имя  : ПОЛНАЯ СТОИМОСТЬ               Домен :             ¦¦¦¦¦    ¦  Необязательн.: N    Формат : MONEY   Длина : 6.2         ¦¦¦¦¦    ¦ Имя  : НОМЕР                          Домен :             ¦¦¦¦¦    ¦  Необязательн.: N    Формат : INTEGER Длина : 9         * ¦¦¦¦¦    ¦ Имя  : ИНДИКАТОР ПОДТВЕРЖДЕНИЯ        Домен :             ¦¦¦¦¦    ¦  Необязательн.: N    Формат : CHAR    Длина : 1           ¦¦¦¦¦    ¦ Имя  : ВРЕМЯ ВЫПИСКИ                  Домен :             ¦¦¦¦¦    ¦  Необязательн.: N    Формат : TIME    Длина :             ¦¦¦¦¦    ¦        * - Атрибуты в первичном уникальном идентификаторе ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ --- СВЯЗИ ----------------------------------------------- ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ :                          ¦¦¦¦¦    ¦                                                           ¦¦¦¦¦    ¦ ДОЛЖНО состоять из     ОДНОГО И БОЛЕЕ      КУПОНОВ        ¦¦¦¦¦    ¦ ДОЛЖНО выписываться  ОДНОЙ И ТОЛЬКО ОДНОЙ                 ¦¦¦¦¦    ¦                                ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ   ¦¦¦+-    ¦ ДОЛЖНО быть для      ОДНОЙ И ТОЛЬКО ОДНОЙ  ЛИЧНОСТИ       ¦¦+-    ¦           * - Связи в первичном уникальном идентификаторе ¦+-    ¦ --- ЗАМЕЧАНИЯ ------------------------------------------- +-    L------------------------------------------------------------                    ------------------------------------------------------------¬       -+----------------------------------------------------------¬¦      -+----------------------------------------------------------¬¦¦     -+----------------------------------------------------------¬¦¦¦     ¦ Date: 01-AUG-89     ORACLE: CASE*Dictionary      Page:  2 ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦               DETAILED ENTITY DEFINITION                  ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ Entity Name: COUPON                  Application:    ATBS ¦¦¦¦     ¦                                      Version    :       1 ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ Sub-type of:                         Reference  :  COUPON ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ Synonyms   :                      Initial Volume:         ¦¦¦¦     ¦                                   Average Volume:   90000 ¦¦¦¦     ¦                                   Maximum Volume:         ¦¦¦¦     ¦                                   Annual Growth%:         ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ --- DESCRIPTION - HAS SIGNIFICANCE AS ------------------- ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ The part of a ticket which entitles the named passenger to¦¦¦¦     ¦ travel on a specified flight of an aircraft, assuming     ¦¦¦¦     ¦ there is an available seat.                               ¦¦¦¦     ¦ The passenger would normally have an (implicitly) associ- ¦¦¦¦     ¦ ated booking and subsequent boarding pass for the same    ¦¦¦¦     ¦ flight.                                                   ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ --- ATTRIBUTES ------------------------------------------ ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ Name : CHECK-IN TIME                 Domain :             ¦¦¦¦     ¦        Opt : Y     Format : TIME     Length : 4           ¦¦¦¦     ¦ Name : COMMENT                       Domain :             ¦¦¦¦     ¦        Opt : Y     Format : CHAR     Length : 20          ¦¦¦¦     ¦ Name : CONFIRMED INDICATOR           Domain : INDICATOR   ¦¦¦¦     ¦        Opt : Y     Format : CHAR     Length : 1           ¦¦¦¦     ¦ Name : FINAL CHECK-IN TIME           Domain :             ¦¦¦¦     ¦        Opt : Y     Format : TIME     Length : 4           ¦¦¦¦     ¦ Name : STATUS                        Domain :             ¦¦¦¦     ¦        Opt : Y     Format : CHAR     Length : 1           ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦               * - Attributes in primary unique identifier ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ --- RELATIONSHIPS --------------------------------------- ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ EACH OCCURRENCE OF THIS ENTITY :                          ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ MUST BE for          ONE AND ONLY ONE  SEAT CLASS         ¦¦¦¦     ¦ MUST BE on           ONE AND ONLY ONE  TICKET           * ¦¦¦¦     ¦ MUST BE open for     ONE AND ONLY ONE  AIRLINE ROUTE    * ¦¦¦¦     ¦ OR                                                        ¦¦¦¦     ¦ MUST BE for          ONE AND ONLY ONE  FLIGHT           * ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦            * - Relationships in primary unique identifier ¦¦+-     ¦                                                           ¦+-     ¦ --- NOTES AND REMARKS ----------------------------------- +-     L------------------------------------------------------------                ------------------------------------------------------------¬       -+----------------------------------------------------------¬¦      -+----------------------------------------------------------¬¦¦     -+----------------------------------------------------------¬¦¦¦     ¦ Дата: 01-AUG-89     ORACLE: CASE*Dictionary      Стр.:  2 ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦            ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ          ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ Имя сущности: КУПОН           Прикладная система:    ATBS ¦¦¦¦     ¦                               Версия            :       1 ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ Супертип    :                 Ссылка            :   КУПОН ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ Синонимы    :                   Начальный объем :         ¦¦¦¦     ¦                                 Средний объем   :   90000 ¦¦¦¦     ¦                                 Максимальн.объем:         ¦¦¦¦     ¦                                 Годовой прирост%:         ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ --- ОПИСАНИЕ - ИМЕЕТ ЗНАЧЕНИЕ --------------------------- ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ Составной части билета для указанного пассажира, связываю-¦¦¦¦     ¦ щей билет с рейсом, самолетом и классом имеющихся мест.   ¦¦¦¦     ¦ Пассажир проходит оформление и получает посадочный талон  ¦¦¦¦     ¦ на указанный рейс.                                        ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ --- АТРИБУТЫ -------------------------------------------- ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ Имя  : КОНТРОЛЬНОЕ ВРЕМЯ              Домен :             ¦¦¦¦     ¦  Необязательн.: Y    Формат : TIME    Длина : 4           ¦¦¦¦     ¦ Имя  : КОММЕНТАРИИ                    Домен :             ¦¦¦¦     ¦  Необязательн.: Y    Формат : CHAR    Длина : 20          ¦¦¦¦     ¦ Имя  : ИНДИКАТОР ПОДТВЕРЖДЕНИЯ        Домен : INDICATOR   ¦¦¦¦     ¦  Необязательн.: Y    Формат : CHAR    Длина : 1           ¦¦¦¦     ¦ Имя  : ОКОНЧАТЕЛЬНОЕ КОНТРОЛЬН.
ВРЕМЯ Домен :             ¦¦¦¦     ¦  Необязательн.: Y    Формат : TIME    Длина : 4           ¦¦¦¦     ¦ Имя  : СТАТУС                         Домен :             ¦¦¦¦     ¦  Необязательн.: Y    Формат : CHAR    Длина : 1           ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦        * - Атрибуты в первичном уникальном идентификаторе ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ --- СВЯЗИ ----------------------------------------------- ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ :                          ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦ ДОЛЖНО быть для      ОДНОГО И ТОЛЬКО ОДНОГО  КЛАССА МЕСТ  ¦¦¦¦     ¦ ДОЛЖНО входить в     ОДИН И ТОЛЬКО ОДИН    БИЛЕТ        * ¦¦¦¦     ¦ ДОЛЖНО быть открыто  ОДНОГО И ТОЛЬКО ОДНОГО               ¦¦¦¦     ¦        для                                 АВИАМАРШРУТА * ¦¦¦¦     ¦ ИЛИ                                                       ¦¦¦¦     ¦ ДОЛЖНО быть для      ОДНОГО И ТОЛЬКО ОДНОГО  РЕЙСА      * ¦¦¦¦     ¦                                                           ¦¦¦¦     ¦           * - Связи в первичном уникальном идентификаторе ¦¦+-     ¦                                                           ¦+-     ¦ --- ЗАМЕЧАНИЯ ------------------------------------------- +-     L------------------------------------------------------------                   ------------------------------------------------------------¬       -+----------------------------------------------------------¬¦      -+----------------------------------------------------------¬¦¦      ¦ Date: 29-SEP-89     ORACLE: CASE*Dictionary      Page:  3 ¦¦¦      ¦                                                           ¦¦¦      ¦               DETAILED ENTITY DEFINITION                  ¦¦¦      ¦                                                           ¦¦¦      ¦ Entity Name: AIRLINE ROUTE           Application:    ATBS ¦¦¦      ¦                                      Version    :       1 ¦¦¦      ¦                                                           ¦¦¦      ¦ Sub-type of:                         Reference  :   ROUTE ¦¦¦      ¦                                                           ¦¦¦      ¦ Synonyms   :                      Initial Volume:         ¦¦¦      ¦                                   Average Volume:      50 ¦¦¦      ¦                                   Maximum Volume:         ¦¦¦      ¦                                   Annual Growth%:       5 ¦¦¦      ¦                                                           ¦¦¦      ¦ --- DESCRIPTION - HAS SIGNIFICANCE AS ------------------- ¦¦¦      ¦                                                           ¦¦¦      ¦ A standard route flown by an airline on an approved       ¦¦¦      ¦ schedule.                                                 ¦¦¦      ¦                                                           ¦¦¦      ¦ --- ATTRIBUTES ------------------------------------------ ¦¦¦      ¦                                                           ¦¦¦      ¦ Name : BOOKABLE SEATS INDICATOR      Domain : INDICATOR   ¦¦¦      ¦        Opt : N     Format : CHAR     Length : 1           ¦¦¦      ¦ Name : FLIGHT NUMBER                 Domain :             ¦¦¦      ¦        Opt : N     Format : CHAR     Length : 6           ¦¦¦      ¦ Name : STANDARD FARE                 Domain :             ¦¦¦      ¦        Opt : N     Format : MONEY    Length : 6.2         ¦¦¦      ¦ Name : STANDARD FARE CURRENCY        Domain : CHAR CODE   ¦¦¦      ¦        Opt : N     Format : CHAR     Length : 3           ¦¦¦      ¦ Name : DEPARTURE DAY                 Domain :             ¦¦¦      ¦        Opt : Y     Format : CHAR     Length : 12          ¦¦¦      ¦ Name : REFRESHMENT TYPE              Domain : CHAR CODE   ¦¦¦      ¦        Opt : Y     Format : CHAR     Length : 3           ¦¦¦      ¦ Name : SCHEDULED ARRIVAL TIME        Domain :             ¦¦¦      ¦        Opt : Y     Format : TIME     Length : 4           ¦¦¦      ¦ Name : SCHEDULED DEPARTURE TIME      Domain :             ¦¦¦      ¦        Opt : Y     Format : TIME     Length : 4           ¦¦¦      ¦                                                           ¦¦¦      ¦               * - Attributes in primary unique identifier ¦¦¦      ¦                                                           ¦¦¦      ¦ --- RELATIONSHIPS --------------------------------------- ¦¦¦      ¦                                                           ¦¦¦      ¦ EACH OCCURRENCE OF THIS ENTITY :                          ¦¦¦      ¦                                                           ¦¦¦      ¦ MUST BE operated by  ONE AND ONLY ONE  AIRLINE          * ¦¦¦      ¦ MUST BE to           ONE AND ONLY ONE  AIRPORT            ¦¦¦      ¦ MUST BE from         ONE AND ONLY ONE  AIRPORT            ¦¦¦      ¦ MUST BE specific to  ONE AND ONLY ONE  PERIOD             ¦¦¦      ¦ MAY BE  normally     ONE AND ONLY ONE  AIRCRAFT TYPE      ¦¦¦      ¦         serviced by                                       ¦¦¦      ¦ MAY BE  referenced on  ONE OR MORE     COUPONS            ¦+-      ¦                                                           +-      L------------------------------------------------------------                   ------------------------------------------------------------¬       -+----------------------------------------------------------¬¦      -+----------------------------------------------------------¬¦¦      ¦ Дата: 28-SEP-89     ORACLE: CASE*Dictionary      Стр.:  3 ¦¦¦      ¦                                                           ¦¦¦      ¦            ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ          ¦¦¦      ¦                                                           ¦¦¦      ¦ Имя сущности: АВИАМАРШРУТ     Прикладная система:    ATBS ¦¦¦      ¦                               Версия            :       1 ¦¦¦      ¦                                                           ¦¦¦      ¦ Супертип    :                 Ссылка            : МАРШРУТ ¦¦¦      ¦                                                           ¦¦¦      ¦ Синонимы    :                   Начальный объем :         ¦¦¦      ¦                                 Средний объем   :      50 ¦¦¦      ¦                                 Максимальн.объем:         ¦¦¦      ¦                                 Годовой прирост%:       5 ¦¦¦      ¦                                                           ¦¦¦      ¦ --- ОПИСАНИЕ - ИМЕЕТ ЗНАЧЕНИЕ --------------------------- ¦¦¦      ¦                                                           ¦¦¦      ¦ Стандартного маршрута, выполняемого авиалинией по утверж- ¦¦¦      ¦ денному расписанию.                                       ¦¦¦      ¦                                                           ¦¦¦      ¦ --- АТРИБУТЫ -------------------------------------------- ¦¦¦      ¦                                                           ¦¦¦      ¦ Имя  : ИНДИКАТОР НАЛИЧИЯ МЕСТ         Домен : INDICATOR   ¦¦¦      ¦  Необязательн.: N    Формат : CHAR    Длина : 1           ¦¦¦      ¦ Имя  : НОМЕР РЕЙСА                    Домен :             ¦¦¦      ¦  Необязательн.: N    Формат : CHAR    Длина : 6           ¦¦¦      ¦ Имя  : СТАНДАРТНАЯ СТОИМОСТЬ          Домен :             ¦¦¦      ¦  Необязательн.: N    Формат : MONEY   Длина : 6.2         ¦¦¦      ¦ Имя  : ВИД ВАЛЮТЫ                     Домен : CHAR CODE   ¦¦¦      ¦  Необязательн.: N    Формат : CHAR    Длина : 3           ¦¦¦      ¦ Имя  : ДЕНЬ ОТПРАВЛЕНИЯ               Домен :             ¦¦¦      ¦  Необязательн.: Y    Формат : CHAR    Длина : 12          ¦¦¦      ¦ Имя  : ТИП ОБСЛУЖИВАНИЯ               Домен : CHAR CODE   ¦¦¦      ¦  Необязательн.: Y    Формат : CHAR    Длина : 3           ¦¦¦      ¦ Имя  : ВРЕМЯ ПРИБЫТИЯ ПО РАСПИСАНИЮ   Домен :             ¦¦¦      ¦  Необязательн.: Y    Формат : TIME    Длина : 4           ¦¦¦      ¦ Имя  : ВРЕМЯ ОТПРАВЛЕНИЯ ПО РАСПИСАН.


Домен :             ¦¦¦      ¦  Необязательн.: Y    Формат : TIME    Длина : 4           ¦¦¦      ¦                                                           ¦¦¦      ¦        * - Атрибуты в первичном уникальном идентификаторе ¦¦¦      ¦                                                           ¦¦¦      ¦ --- СВЯЗИ ----------------------------------------------- ¦¦¦      ¦                                                           ¦¦¦      ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ :                          ¦¦¦      ¦                                                           ¦¦¦      ¦ ДОЛЖНО обслуживаться ОДНОЙ И ТОЛЬКО ОДНОЙ  АВИАЛИНИЕЙ   * ¦¦¦      ¦ ДОЛЖНО быть в        ОДИН И ТОЛЬКО ОДИН    АЭРОПОРТ       ¦¦¦      ¦ ДОЛЖНО быть из       ОДНОГО И ТОЛЬКО ОДНОГО  АЭРОПОРТА    ¦¦¦      ¦ ДОЛЖНО быть связано с ОДНИМ И ТОЛЬКО ОДНИМ   ПЕРИОДОМ     ¦¦¦      ¦ МОЖЕТ  обычно        ОДНИМ И ТОЛЬКО ОДНИМ  ТИПОМ САМОЛЕТА ¦¦¦      ¦        обслуживаться                                      ¦¦¦      ¦ МОЖЕТ  указываться на  ОДНОМ И БОЛЕЕ       КУПОНАХ        ¦+-      ¦                                                           +-      L------------------------------------------------------------           ------------------------------------------------------------¬       -+----------------------------------------------------------¬¦       ¦ Date: 29-SEP-89     ORACLE: CASE*Dictionary      Page:  4 ¦¦       ¦                                                           ¦¦       ¦               DETAILED ENTITY DEFINITION                  ¦¦       ¦                     (CONTINUATION)                        ¦¦       ¦ Entity Name: AIRLINE ROUTE           Application:    ATBS ¦¦       ¦                                      Version    :       1 ¦¦       ¦                                                           ¦¦       ¦ Sub-type of:                         Reference  :   ROUTE ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦ --- RELATIONSHIPS --------------------------------------- ¦¦       ¦                                                           ¦¦       ¦ EACH OCCURRENCE OF THIS ENTITY :                          ¦¦       ¦                                                           ¦¦       ¦ MAY BE  covered by     ONE OR MORE     NORMAL CREW        ¦¦       ¦                                        MEMBERSHIPS        ¦¦       ¦ MAY BE  scheduled as   ONE OR MORE     SCHEDULED FLIGHTS  ¦¦       ¦ MAY BE  additionally   ONE OR MORE     STANDARD CREW      ¦¦       ¦         serviced by                    MEMBERSHIPS        ¦¦       ¦ MAY BE normally serviced by ONE AND ONLY ONE              ¦¦       ¦                                                           ¦¦       ¦            * - Relationships in primary unique identifier ¦¦       ¦                                                           ¦¦       ¦ --- NOTES AND REMARKS ----------------------------------- ¦¦       ¦                                                           ¦¦       ¦ --------------------------------------------------------- ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           +-       L------------------------------------------------------------                ------------------------------------------------------------¬       -+----------------------------------------------------------¬¦       ¦ Дата: 28-SEP-89     ORACLE: CASE*Dictionary      Стр.:  4 ¦¦       ¦                                                           ¦¦       ¦            ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ          ¦¦       ¦                      (ПРОДОЛЖЕНИЕ)                        ¦¦       ¦ Имя сущности: АВИАМАРШРУТ     Прикладная система:    ATBS ¦¦       ¦                               Версия            :       1 ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦ --- СВЯЗИ ----------------------------------------------- ¦¦       ¦                                                           ¦¦       ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ :                          ¦¦       ¦                                                           ¦¦       ¦ МОЖЕТ   обслуживаться  ОДНОЙ И БОЛЕЕ   ДОЛЖНОСТЯМИ В      ¦¦       ¦                                        ОБЫЧНОМ ЭКИПАЖЕ    ¦¦       ¦ МОЖЕТ   планироваться  ОДИН И БОЛЕЕ    РЕЙСОВ             ¦¦       ¦         как                                               ¦¦       ¦ МОЖЕТ   дополнительно  ОДНУ И БОЛЕЕ    ДОЛЖНОСТЕЙ В       ¦¦       ¦         определять                     СТАНДАРТНОМ ЭКИПАЖЕ¦¦       ¦                                                           ¦¦       ¦           * - Связи в первичном уникальном идентификаторе ¦¦       ¦                                                           ¦¦       ¦ --- ЗАМЕЧАНИЯ ------------------------------------------- ¦¦       ¦                                                           ¦¦       ¦ --------------------------------------------------------- ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           ¦¦       ¦                                                           +-       L------------------------------------------------------------                ------------------------------------------------------------¬        ¦ Date: 29-SEP-89     ORACLE: CASE*Dictionary      Page:  5 ¦        ¦                                                           ¦        ¦               DETAILED ENTITY DEFINITION                  ¦        ¦                                                           ¦        ¦ Entity Name: CREW ASSIGNMENT         Application:    ATBS ¦        ¦                                      Version    :       1 ¦        ¦                                                           ¦        ¦ Sub-type of:                         Reference  : CREW ASS¦        ¦                                                           ¦        ¦ Synonyms   :                      Initial Volume:         ¦        ¦                                   Average Volume:   85000 ¦        ¦                                   Maximum Volume:         ¦        ¦                                   Annual Growth%:         ¦        ¦                                                           ¦        ¦                                                           ¦        ¦ --- DESCRIPTION - HAS SIGNIFICANCE AS ------------------- ¦        ¦                                                           ¦        ¦ An allocation of a person, who must be an existing member ¦        ¦ of a crew, to either a complete flight or a component of  ¦        ¦ a flight.


Each assignment is within the context of a      ¦        ¦ specific crew role, which may differ from their normal    ¦        ¦ crew role. Eg A captain acting as a second pilot.         ¦        ¦                                                           ¦        ¦ --- ATTRIBUTES ------------------------------------------ ¦        ¦                                                           ¦        ¦ Name : DATE CANCELLED                Domain :             ¦        ¦        Opt : Y     Format : DATE     Length :             ¦        ¦ Name : DATE MADE                     Domain :             ¦        ¦        Opt : Y     Format : DATE     Length :             ¦        ¦ Name : SPECIAL DUTY                  Domain :             ¦        ¦        Opt : Y     Format : CHAR     Length : 80          ¦        ¦                                                           ¦        ¦               * - Attributes in primary unique identifier ¦        ¦                                                           ¦        ¦ --- RELATIONSHIPS --------------------------------------- ¦        ¦                                                           ¦        ¦ EACH OCCURRENCE OF THIS ENTITY :                          ¦        ¦                                                           ¦        ¦ MUST BE in           ONE AND ONLY ONE  CREW ROLE          ¦        ¦ MUST BE of           ONE AND ONLY ONE  PERSON           * ¦        ¦                                                           ¦        ¦ MUST BE to           ONE AND ONLY ONE  FLIGHT           * ¦        ¦ OR                                                        ¦        ¦ MUST BE to           ONE AND ONLY ONE  FLIGHT COMPONENT * ¦        ¦                                                           ¦        ¦            * - Relationships in primary unique identifier ¦        ¦                                                           ¦        ¦ --- NOTES AND REMARKS ----------------------------------- ¦        ¦                                                           ¦        ¦ --------------------------------------------------------- ¦        ¦                                                           ¦        L------------------------------------------------------------                ------------------------------------------------------------¬        ¦ Дата: 01-AUG-89     ORACLE: CASE*Dictionary      Стр.:  5 ¦        ¦                                                           ¦        ¦            ДЕТАЛИЗИРОВАННОЕ ОПРЕДЕЛЕНИЕ СУЩНОСТИ          ¦        ¦                                                           ¦        ¦ Имя сущности: НАЗНАЧЕНИЕ В    Прикладная система:    ATBS ¦        ¦               ЭКИПАЖ          Версия            :       1 ¦        ¦                                                           ¦        ¦ Супертип    :                 Ссылка            :  ЭКИПАЖ ¦        ¦                                                           ¦        ¦ Синонимы    :                   Начальный объем :         ¦        ¦                                 Средний объем   :   85000 ¦        ¦                                 Максимальн.объем:         ¦        ¦                                 Годовой прирост%:         ¦        ¦                                                           ¦        ¦                                                           ¦        ¦ --- ОПИСАНИЕ - ИМЕЕТ ЗНАЧЕНИЕ --------------------------- ¦        ¦                                                           ¦        ¦ Назначения личности, являющейся членом экипажа, либо на   ¦        ¦ весь рейс, либо на его часть.


Каждое назначение произво-  ¦        ¦ дится в контексте конкретной роли, выполняемой в экипаже, ¦        ¦ которая может отличаться от обычной роли члена экипажа.   ¦        ¦ Так, например, командир может действовать в качестве вто- ¦        ¦ рого пилота.                                              ¦        ¦                                                           ¦        ¦ --- АТРИБУТЫ -------------------------------------------- ¦        ¦                                                           ¦        ¦ Имя  : ДАТА ОТМЕНЫ                    Домен :             ¦        ¦  Необязательн.: Y    Формат : DATE    Длина :             ¦        ¦ Имя  : ДАТА ПРОИЗВОДСТВА              Домен :             ¦        ¦  Необязательн.: Y    Формат : DATE    Длина :             ¦        ¦ Имя  : ОСОБАЯ ОБЯЗАННОСТЬ             Домен :             ¦        ¦  Необязательн.: Y    Формат : CHAR    Длина : 80          ¦        ¦                                                           ¦        ¦        * - Атрибуты в первичном уникальном идентификаторе ¦        ¦                                                           ¦        ¦ --- СВЯЗИ ----------------------------------------------- ¦        ¦                                                           ¦        ¦ КАЖДОЕ ВХОЖДЕНИЕ ЭТОЙ СУЩНОСТИ :                          ¦        ¦                                                           ¦        ¦ ДОЛЖНО быть на       ОДНУ И ТОЛЬКО ОДНУ    РОЛЬ В ЭКИПАЖЕ ¦        ¦ ДОЛЖНО быть для      ОДНОЙ И ТОЛЬКО ОДНОЙ  ЛИЧНОСТИ     * ¦        ¦                                                           ¦        ¦ ДОЛЖНО производиться ОДНОГО И ТОЛЬКО ОДНОГО  РЕЙСА      * ¦        ¦        для                                                ¦        ¦ ИЛИ                                                       ¦        ¦ ДОЛЖНО производиться ОДНОЙ И ТОЛЬКО ОДНОЙ  ЧАСТИ РЕЙСА  * ¦        ¦        для                                                ¦        ¦                                                           ¦        ¦           * - Связи в первичном уникальном идентификаторе ¦        ¦                                                           ¦        ¦ --- ЗАМЕЧАНИЯ ------------------------------------------- ¦        ¦                                                           ¦        ¦ --------------------------------------------------------- ¦        ¦                                                           ¦        L------------------------------------------------------------

J. МОДЕЛИ ДРУГИХ ТИПОВ

МВМС является средством, которое используется многими методологиями проектирования; однако, понятия, которыми оно манипулирует, изображаются на схемах часто по-разному. Все альтернативные способы представления мы не в состоянии охватить, но некоторые мы приведем в качестве иллюстрации выдвинутого положения.
Сначала повторим одну из схем, уже встречавшуюся в книге, а затем представим ее альтернативными способами.
Рисунок J-1. Модель заказа и его строк, построенная с учетом принятых в CASE*Method'е соглашений

Рисунок J-2. Модель SSADM (методология проектирования систем на базе структурного анализа)

Легко заметить, что связи типа "один ко многим", как и исключающие дуги, выглядят так же. В то же время подтипы, уникальные идентификаторы и непереносимые связи не представлены вообще. На мысль о подтипах наводит исключающая дуга, покрывающая связи сущности ЗАКАЗ.
Используемые "ролевые" атрибуты указывают на способ осуществления связи; например, номер заказа, повторенный у сущности СТРОКА, ОПИСЫВАЮЩАЯ ПРОДУКТ, отражает связь последней с сущностью ЗАКАЗ.
Рисунок J-3. Модель IEM (методология информационного проектирования)

Здесь указатель необязательности связи --o-- присутствует на противоположном конце (в отличие от CASE*Method'а). Символом --+-- обозначается конец связи со степенью "один".
CASE*Method по существу является методологией информационного проектирования, охватывающей большинство понятий МВМС и использующей различные соглашения.
                Chen Model (Модель Чена)                ---------------¬     n                    1   ---------------¬        ¦СТРОКА, ОПИСЫ-+----------< описывает >-------+    ПРОДУКТ   ¦        ¦ВАЮЩАЯ ПРОДУКТ+---¬                          LT-------T------        L------T--------   ¦                           ¦       ¦               ¦           ¦                       ====¦    ---+----               ¦ 1         ¦ n                   << код >>< описание >               ¦           ¦                       =====    --------               ¦           ¦                      1   ---------------¬          < является >     L------< описывает >-------+    УСЛУГА    ¦               ¦                                      LT-------T------               ¦                                       ¦       ¦               ¦ 0                                 ====¦    ---+----               ¦                                 << код >>< описание >               ¦                                   =====    --------        -------+-------¬    0                     1   ---------------¬        ¦СТРОКА ЗАКАЗА +----------< является >--------+ПРОЧАЯ СТРОКА ¦        LT----TT--------                              ¦    ЗАКАЗА    ¦         ¦    ¦¦                                      L---------------     ====¦==  ¦¦                                              ^   << номер >>¦¦ n                                            ¦     =======  ¦¦                                              ¦           ----¦                                           Сущность     ------+-  ¦   < описание >¦     --------  ¦               ¦          < содержит >  <-------------------------------T- Связь               ¦ 1          0                           ¦        -------+-------T--------¬                       ¦        ¦    ЗАКАЗ     ¦        +-< включает >   <-------        L----T--------T+---------             ¦        ¦     n           --+-      =¦=====         < дата >  << номер >>           ----      =======
В данной модели, хотя это и не видно на схеме, предполагаются не только бинарные связи (т.е. связи, имеющие строго два конца). Здесь, как и в методе Мерайза (Merise), одна связь может соединять две, три и более сущностей, кроме того она может иметь свои собственные атрибуты.
В противоположность сущностям и связям, атрибуты изображаются в виде эллипсов, а уникальные идентификаторы, кроме того, обводятся двойной линией. Дабы не усложнять схему, часть атрибутов на ней пришлось опустить. Подтипы обозначаются бинарными связями типа "один к одному", исключительность и непереносимость связей не показывается вообще.

Пример, связанный с билетами на самолет

Главным овеществленным понятием, которое нас будет интересовать в путешествиях по воздуху, выступает в данном примере авиабилет, подтверждающий перелет из, ну скажем, Атлантии - столицы архипелага Атлантис - в Париж. Если посмотреть внимательно, можно заметить, что авиабилет состоит из купонов (отрывных талонов), каждый из которых соответствует перелету между двумя аэропортами. Выглядеть такой билет будет следующим образом:
Рисунок 2-1. Авиабилет

Билет состоит из двух купонов - один для перелета из Атлантии в Лондон, другой для перелета из Лондона в Париж. Третий лист содержит описание всего маршрута путешествия.
Рисунок 2-2. Купон к авиабилету

Начнем рассмотрение информационной области с выполняющего полет самолета.
Каждый самолет, как правило, за день выполняет несколько рейсов, однозначно определяемых датой и временем вылета, номером рейса и аэропортом отправления. Из номера рейса можно почерпнуть два указания: на авиакомпанию, обслуживающую полет (так "AIF" соответствует авиакомпании "Atlantis Island Flights"), и на маршрут, по которому выполняется полет. Отсюда нас будет интересовать, какими самолетами выполняются полеты, сколько продано билетов, какие рейсы получили подтверждение и какие места выделены для пассажиров.
Рисунок 2-3. Модель взаимосвязей для сущности "Билет"

Ядром такой системы выступает купон. Он означает примерно то же, что и наименьший общий делитель в математике, и ему присущи такие информационные характеристики, как класс и статус. Купон может существовать только при наличии (в контексте) авиабилета, от которого он наследует дату выписки и стоимость.
Каждый из блоков на Рисунке 2-3 заключает в себе сущность, а линия, соединяющая между собой блоки, соответствует связи между сущностями. Разветвляющееся окончание такой линии у левого блока и одинарное окончание у правого говорят о том, что у одного билета может быть много купонов; мы имеем дело со связью типа "многие к одному". Непрерывная линия говорит о том, что связь обязательная.
Связь может читаться слева направо:
Каждый КУПОН должен входить в один и только один БИЛЕТ и справа налево:
Каждый БИЛЕТ должен состоять из одного или более КУПОНОВ. Следует отметить, что выражение "должен" свидетельствует об обязательном характере связи.
А что можно сказать о рейсе ?
Рисунок 2-4. Связь между сущностями БИЛЕТ и РЕЙС

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

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

Модель, изображенная на рисунке 2-5, содержит уже достаточно информации для того, чтобы стать моделью авиабилета. Обратите внимание на то, что мы уже изобразили в виде блоков все объекты, упомянутые на билете. Нами добавлены блоки, соответствующие сущностям ПАССАЖИР, АЭРОПОРТ, АВИАЛИНИЯ и, пожалуй, наиболее сложной для понимания сущности АВИАМАРШРУТ.
Авиамаршрут однозначно идентифицируется номером рейса и курирующей его авиалинией. На билете ему соответствует составной код AIF213 или AIF217.
У нас появилась возможность прочитать всю схему относительно сущности АВИАЛИНИЯ:
Каждая АВИАЛИНИЯ может курировать один и более АВИАМАРШРУТОВ, каждый из которых может планироваться как один и более РЕЙСОВ, описываемых датой и временем вылета. В соответствии со схемой, каждый рейс должен выполняться по АВИАМАРШРУТУ (заранее определенному) и должен следовать из одного АЭРОПОРТА в другой.
Это общеупотребимый и обязательный набор правил. На приведенное утверждение можно посмотреть с двух разных углов.
Угол 1: Какие рейсы выполняются из аэропорта Атлантии любой из авиалиний? Эта информация обычно в первую очередь интересует вылетающих пассажиров.
Рисунок 2-6 . Отправление рейсов по аэропортам

Отправление Аэропорт: Атлантия
Авиалиния	Номер рейса	Отправление	Место назначения
дата	время
BA AIF AIF BA TW	962 213 004 964 51	3 Янв 89 3 Янв 89 3 Янв 89 3 Янв 89 3 Янв 89	07:30 08:00 08:15 09:00 09:15	Лондон Лондон Нью-Йорк Манчестер Чикаго

Угол 2: Какие рейсы, отправляющиеся из Атлантии, выполняются авиалинией "Atlantis Island Flights"?
Эта информация используется компанией AIF для слежения за своими рейсами.


Рисунок 2-7. Отправление рейсов по авиалиниям

Отправление Авиалиния: Atlantia Island Flights (AIF) Аэропорт: Атлантия
Номер рейса	Место назначения	Отправление
дата	время
213 004 009	Лондон LHR Нью-Йорк JFK Южный Остров AASI	3 Янв 89 3 Янв 89 3 Янв 89	08:00 08:15 09:20

Другими словами, современные авиалинии должны иметь систему (автоматическую или неавтоматическую) для регистрации, выдачи и контроля информации, представленной на схеме.
Механизм создания схемы
В каждом случае, когда информация на билете или купоне ссылается на нечто из реального мира, мы создаем сущность, соответствующую этому нечто, оформляем ее в виде блока, записываем в нем заглавными буквами название, а строчными - атрибуты. Так, например, сущность АВИАЛИНИЯ имеет атрибут "код". При обнаружении связи между двумя сущностями мы соединяем их линией и делаем надписи, характеризующие степень участия сущности в этой связи.
В реальном мире для обозначения связей часто используются коды и названия. Так, например, на изображении купона к билету (Рисунок 2-2) код AIF указан в столбце, озаглавленном "Трансагентство", для обозначения связи с авиалинией "Atlantis Island Flights". На нашей схеме, однако, эта косвенная связь показана линиями, соединяющими сущности КУПОН, РЕЙС, АВИАМАРШРУТ и АВИАЛИНИЯ, а "AIF" - только значение атрибута "код" сущности АВИАЛИНИЯ.
Однако, на схеме еще пока отсутствует информация о самолете, подтверждении полета и выделении мест. Схема с этой информацией представлена на Рисунке 2-8.
Рассмотрим же информацию под тем углом, как она соотносится с сущностью САМОЛЕТ.
Каждый САМОЛЕТ может назначаться на один и более РЕЙСОВ с датой и временем вылета и
Каждый РЕЙС должен выполняться по стандартному АВИАМАРШРУТУ из одного АЭРОПОРТА в другой.
(В модели допускаются даже авиамаршруты, где аэропорт отправления совпадает с аэропортом назначения ! Это может пригодиться для тех пассажиров, кто получает удовольствие просто от двухчасового пребывания на борту Конкорда.)


При выделении мест каждый пассажир должен быть обеспечен местом на борту самолета. Эта задача решается с помощью посадочного талона, выписываемого на основании купона и могущего рассматриваться в качестве его синонима или второго наименования.
Каждый САМОЛЕТ может иметь одно и более МЕСТ, каждое из которых может выделяться на основании одного и более КУПОНОВ (или ПОСАДОЧНЫХ ТАЛОНОВ) на РЕЙС с определенной датой и временем вылета.
Обратите внимание на то, что мы связали билет с пассажиром и разрешили пассажиру иметь более одного билета одновременно.
Каждый билет должен предназначаться для одного и только одного ПАССАЖИРА, который, в свою очередь, может быть указан на одном и более БИЛЕТАХ.
Сущность ПАССАЖИР может пригодиться нам в дальнейшем, если мы захотим помочь авиалинии индивидуализировать свои услуги, т.е. учитывать предпочтения пассажира на занятие тех или иных мест.
В надежной системе необходимо обеспечить уникальность выписываемых посадочных талонов для каждого рейса, хотя до закрепления мест за пассажирами некоторое превышение количества продаваемых билетов считается нормой.
На основании посадочных талонов мы можем получить список пассажиров, принятых на борт самолета, что может пригодиться в каких -нибудь чрезвычайных обстоятельствах, а также в том случае, если за несколько минут до вылета пассажир еще не попал на борт. Можно представить в графическом виде, как эта информация будет отображаться в реальной системе.
Рисунок 2-8. Расширенная модель

Рисунок 2-9. Схема выделения мест

На рисунке представлен вариант экранной формы для настольной системы распределения мест на самолет. Она представляет собой как бы внутренний план самолета в графической форме - иллюстрацию взаимосвязи между местом и самолетом типа "многие к одному". Для отнесения места к типу "для курящих" или "для некурящих" используется штриховка; на нашей модели взаимосвязей между сущностями ей соответствует атрибут "признак разрешения курения" сущности МЕСТО.В нашем случае место D4 выбрано с помощью манипулятора "мышь"; в появившемся окне разрешен ввод или подтверждение сведений о пассажире. После заполнения полей окна можно нажатием клавиши "OK" закончить работу с ним.

Кредитная компания открывает счета либо

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

компания (организация)

счет

частное лицо

карточка (или лучше сказать, кредитная карточка)

служащий.

Все эти понятия можно считать сущностями.
В параграфе нам встретились и некоторые другие понятия и выражения:

тип карточки

лимит

условие платежа

прочее условие.

Возможно, что часть из них является атрибутами, поскольку позволяет описывать другие объекты.
Попытаемся связать их с сущностями.
Является ли " тип карточки" атрибутом карточки или самостоятельной сущностью? Если это сущность, то она должна представлять собой важный объект, информация о котором подлежит выяснению или запоминанию. В этом случае это так, поскольку "лимит" и "условие платежа" являются атрибутами "типа карточки". Экземпляром ТИПА КАРТОЧКИ будет такой тип, у которого лимит равен двумстам долларов, а условие платежа требует полного расчета по окончании месяца - идеальный тип для моих детей, каждому из которых пригодилась бы подобная карточка.
Какие при этом возможны связи? Они обнаруживаются в нескольких парах сущностей по следующим фразам:
КОМПАНИЯ открывает СЧЕТА
СЧЕТ либо для ЧАСТНОГО ЛИЦА, либо для КОМПАНИИ
КОМПАНИЯ... своим СЛУЖАЩИМ.
КОМПАНИЯ появляется дважды - один раз как кредитная, а второй раз как организация-клиент кредитной компании. Предположим, что кредитная компания - просто контекст для данного примера и ею можно пренебречь.
Обратите внимание на фразу "либо..., либо...", появляющуюся в ситуации со СЧЕТАМИ. Для того, чтобы перенести ее на модель, нам потребуется новое соглашение - т.н. "исключающая связь", которая на схеме изображается в виде двух перечеркнутых одной дугой линий связи:
Рисунок 4-1. Исключающая дуга

Читается это так:
Каждый СЧЕТ должен быть либо для одного и только одного ЧАСТНОГО ЛИЦА, либо для одной и только одной КОМПАНИИ.
Эта небольшая подмодель, конечно, неполна, но на данном этапе полезна. На ней видна связь типа "многие к одному", существующая между СЧЕТАМИ (множеством) и КОМПАНИЕЙ (одной). Описание связи на другом конце пока отсутствует и будет получено при дальнейшей отладке.
Второй параграф
С каждым счетом, будь то счет частного лица или организации, может быть связано множество карточек. Необходимо знать, кто является владельцем каждой из них. Физически это решается путем указания на карточке имени ее владельца (держателя) в сочетании с номером счета и датой истечения срока действия.


Рассмотрим следующие понятия:

счет частного лица (персональный счет)

счет организации (компании)

владелец карточки.

Перечень возможных атрибутов:

имя владельца карточки

номер счета

дата истечения срока действия (короче: срок действия).

Перечень возможных связей:
КАРТОЧКИ... связаны с ПЕРСОНАЛЬНЫМ СЧЕТОМ
КАРТОЧКИ... связаны со СЧЕТОМ КОМПАНИИ
Эти связи имеют тип "многие к одному".
Остальные параграфы
Возможные сущности:

счет

карточка

супруга

компания-клиент (организация)

ребенок

кредитная компания

тип карточки.

Возможный атрибут:
·
очень низкая предельная сумма (лимит).
Возможные связи:

СЧЕТ с КАРТОЧКОЙ

КОМПАНИЯ имеет СЧЕТ

КАРТОЧКА для ВАС

СЧЕТ у СУПРУГИ

КАРТОЧКИ для ДЕТЕЙ

КАРТОЧКИ различных ТИПОВ.

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

частное лицо

служащий

владелец карточки

супруга

ребенок.

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

дата начала действия

срок действия

дата выпуска

подпись.

Все остальное на карточке относится к связи или к типу карточки.
Как можно уникально идентифицировать карточку?
Сравните вашу черновую модель с представленной на следующей странице.

и услуги являются вхождениями одной

Заказы
Рисунок 8-23. Классическая структура для заказов

Замечания:
На этой схеме продукты и услуги являются вхождениями одной и той же сущности.
Подтип ПРОЧАЯ СТРОКА ЗАКАЗА адресует нас к налогам, условиям поставки, комментариям и т.п. по данному заказу.
Модель позволяет отслеживать многоуровневую иерархию подзаказов, входящих в данный заказ (что имеет решающее значение для контроля).
Поставщик и покупатель выделены в отдельные сущности, что характерно для малого бизнеса. В более общем случае их следовало бы объединить, чтобы иметь возможность охватить и внутренние заказы.
Если учесть внутренние заказы, можно составить довольно интересный список возможных синонимов и примеров:

ЗАКАЗ	Контракт Соглашение Лицензия Tребование Внутренний заказ
ОСНОВНОЙ ЗАКАЗ	Основной контракт Первоочередной контракт
ПОДЧИНЕННЫЙ ЗАКАЗ	Подконтракт Подзаказ
Примеры	Контракт на ремонт и обслуживание Соглашение об оказании услуг Контракт с фиксированной ценой Материальный контракт

Другие документы
Попробуйте заменить на схеме слово ЗАКАЗ на слово ПОСТАВКА (или ЗАЯВКА). Возникнет необходимость в некоторых изменениях, но сама форма останется неизменной, поскольку воплощает основные принципы, заложенные в различных контролируемых документах.
Роли и занятия
Начнем с перечня примеров:
Роли - выполняющий заказы, покупатель, продавец, оказывающий первую помощь, руководитель проекта, лектор, поденщик.
Занятия - менеджер, клерк, торговый агент, монтер, сиделка, учитель, программист.
Замечания:
На схеме, которую мы разберем, типы ролей и занятий показаны отдельно друг от друга.
Тип занятия можно расширить таким образом, что он будет включать ранг и соответствующую оплату, полное описание обязанностей и т.п. Здесь мы только отделили ЦЕЛИ от ролей. На более детализированной модели можно произвести дифференциацию и внутри целей.
Мы предположили, что ДОГОВОР О НАЙМЕ имеет отношение только к ВНУТРЕННИМ ОРГАНИЗАЦИОННЫМ ЕДИНИЦАМ.
Заменив эту связь на связь с супертипом (ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ), мы сможем отслеживать занятия, выполняемые людьми одновременно, ныне, в прошлом и планирующиеся к выполнению в будущем.
Во многих странах вместо слов ДОГОВОР О НАЙМЕ используется НАЗНАЧЕНИЕ НА ДОЛЖНОСТЬ; то есть люди назначаются на должность (тип занятия) через официальное оформление договора о найме или без оного.
Рисунок 8-24. Классическая структура для ролей и занятий.

Продукты
Если мы объединим некоторые из предыдущих примеров, мы получим следующую схему для контроля за продуктами.
Рисунок 8-25. Классическая структура для продуктов и занятий

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

прогнозов

бюджетов

отчетов и сводок.

Схема, составленная нами, войдет в обобщенную модель.
Шаг 1
Рассмотрим проект, содержащий ряд прогнозов, которые в принципе могут пересматриваться.
Рисунок 8-26. Базовая структура

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


Рисунок 8-27. Добавление подтипов и фактора времени

Шаг 3
Поэтому попробуем создать некоторую обобщающую сущность с именем ЭЛЕМЕНТ ПРОЕКТНОГО ПЛАНИРОВАНИЯ, выделив ТИП ПЛАНА, который может содержать столько вхождений, сколько нам будет нужно.
Рисунок 8-28. Использование новых сущностей для создания более универсальной структуры (структуры с более высоким уровнем обобщения)

Шаг 4
Чтобы продолжить классификацию прогнозов, бюджетов, планов и т.п., часто обращаются к типу используемого ресурса. Иногда даже доходят до конкретного вхождения; например, использование конкретного здания или компьютера. Все это можно увидеть на следующей схеме, где слово "редко" дополнительно характеризует новую связь.
Рисунок 8-29. Переход к ресурсам

Шаг 5
От планов перейдем к оценке фактического использования ресурсов. Для оценки можно воспользоваться такими материалами, как табели для персонала, документы по финансовым сделкам и различным механизмам распределения материальных ресурсов и имущества (например, наем помещений). При этом чаще идет речь о типах ресурсов, нежели о конкретных ресурсах.
Рисунок 8-30. Использование ресурсов

Шаг 6
Если нас интересует сведение фактических данных за конкретный период, модель станет еще более сложной.
Рисунок 8-31. Расширенная структура

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

Элемент планирования

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

Сводка по проекту

Таким образом, мы можем перейти к схеме, позволяющей вести обработку управленческой информации с учетом всевозможных обстоятельств. Сущность ПРОЕКТ можно заменить на сущность КУРС ОБУЧЕНИЯ, СЧЕТ или РАЗРАБОТКА ПРОДУКТА.
Рисунок 8-32. Обобщенная модель

Проблемное представление

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

атрибуты данной сущности плюс

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

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

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

Проблемное представление сущности КУПОН включает в себя:

КУПОН (текущая сущность)		класс статус индикатор подтверждения комментарии
РЕЙС		дата вылета время вылета
АВИАМАРШРУТ		номер рейса время отправления по расписанию
АВИАЛИНИЯ		код название
АЭРОПОРТ (из)		код название
АЭРОПОРТ (в)		код название
БИЛЕТ		дата выписки стоимость вид валюты (денежная единица)
ЛИЧНОСТЬ		фамилия титул первая буква имени

Обратите внимание на то, что поскольку между АВИАМАРШРУТОМ и АЭРОПОРТОМ существуют две связи, описания связей используются в качестве уточнения.
Вы еще убедитесь в том, что такое простое на первый взгляд представление оказывается полезным, когда встает задача двойной проверки бумажной документации, формата файлов и т.п.
Проблемное представление сущности РЕЙС:

РЕЙС		дата вылета время вылета
АВИАМАРШРУТ		номер рейса время отправления по расписанию
АВИАЛИНИЯ		код название
АЭРОПОРТ (из)		код название
АЭРОПОРТ (в)		код название

<
Расширение представления

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

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

Реальный пример построить сложно, поэтому воспользуемся следующей иллюстрацией:

Рисунок G-2. Модель, состоящая из более сложных компонент



Проблемное представление для каждого вхождения сущности A может быть либо таким:

A	a1, a2, a3	(текущая сущность)
C	c1, c2, c3
D	d1, d2, d3	(все необязательные)
F	f1, f2, f3

либо таким:

A	a1,a2,a3
C	c1,c2,c3
D	d1,d2,d3	(все необязательные)
E	e1,e2,e3
E (компонента)	e1,e2,e3...	(все необязательные)

Обратите внимание на то, что любое реальное вхождение сущности A может иметь атрибуты либо сущности E, либо сущности F, но не и те и другие одновременно, т.к. связи между сущностью A и сущностями E и F взаимно исключающие.

Поименованные проблемные представления

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

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

Рисунок G-3.



Напомним еще раз проблемное представление сущности РЕЙС:

РЕЙС	дата вылета время вылета
АВИАМАРШРУТ	номер рейса время отправления по расписанию
АВИАЛИНИЯ	код название
АЭРОПОРТ (из)	код название
АЭРОПОРТ (в)	код название

<


Поскольку между АВИАМАРШРУТОМ и АЭРОПОРТОМ существуют две альтернативные связи, описания связей используются в качестве уточнения.

Теперь мы можем создать проблемное представление с именем РЕГУЛЯРНЫЙ РЕЙС и со следующей структурой:

Рисунок G-4.



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

Легко заметить, что вместо "Названия авиалинии" используется просто "Авиалиния" - такое использование имени сущности или синонима в качестве наименования атрибута является общим и привычным.

Термины "Место назначения" и "Исходный пункт" отражают назначение (роль) сущности АЭРОПОРТ, вытекающее из ее связей с сущностью АВИАМАРШРУТ.

Теперь мы можем составить определения функций, работающих с сущностью РЕГУЛЯРНЫЙ РЕЙС.

Пример 1

Установить номер рейса и дату вылета по расписанию для всех регулярных рейсов, отправляющихся из аэропорта "Хитроу" в мае 1989 года в одно место назначения более одного раза в день.

Пример 2

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

Создать по требованию вхождение сущности РЕЙС на определенную дату для конкретного АВИАМАРШРУТА, идентифицируемого номером рейса из АЭРОПОРТА отправления с определенным названием в АЭРОПОРТ назначения с определенным названием и обслуживаемого АВИАЛИНИЕЙ с соответствующим кодом, где: название АЭРОПОРТА отправления не совпадает с названием АЭРОПОРТА назначения.

С помощью проблемного представления РЕГУЛЯРНЫЙ РЕЙС это определение можно упростить:

Создать по требованию вхождение сущности РЕГУЛЯРНЫЙ РЕЙС, используя известные значения даты отправления по расписанию, номера рейса, времени вылета, авиалинии, места назначения и исходного пункта, где место назначения не совпадает с исходным пунктом.

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

Таким образом, определение функции может стать еще короче: Создать по требованию вхождение сущности РЕГУЛЯРНЫЙ РЕЙС, в котором место назначения не совпадает с исходным пунктом.

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

Продолжение рассказа о компании "Atlantis Island Flights"

В целях обеспечения гибкости в обслуживании клиентов компания "Atlantis Island Flights" предоставляет своим клиентам возможность приобретения билетов с т.н. открытыми купонами. Это удобно для тех, кто регулярно летает по одному маршруту и желает иметь оплаченный вперед билет, которым можно было бы воспользоваться в любой день. Это также удобно в случае предварительного оформления билетов на обратную дорогу, если продолжительность поездки заранее неизвестна.
Рисунок 6-1. Билет с открытой датой вылета

Рейсы, таким образом, можно разбить на две категории - регулярные (по расписанию) и вне расписания.
Персоналу авиакомпании выделяются специальные билеты. Они выглядят как обычные билеты с открытой датой вылета, но имеют на купоне цветную полосу. По заведенному в компании порядку не более 10 ее сотрудников, включая 5 членов экипажей, могут путешествовать на любом рейсе в качестве пассажиров. Представляют интерес имена и должности этих сотрудников (на крайний случай). Специальные билеты не имеют стоимости, поскольку предоставляются от лица компании. Если те же сотрудники путешествуют как частные лица, для них сохраняются общие правила - их билеты содержат данные о полной стоимости, включая предусмотренную для персонала скидку. (Прочие виды скидок также время от времени имеют место в разных обстоятельствах.)
Члены экипажа строго проверяются - по уровню мастерства и составу выполняемых работ. На каждый пассажирский рейс составляется список членов экипажа, учитывающий только тип самолета.
Рисунок 6-2. Состав экипажа

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

Производные атрибуты

Прежде чем завершить обзор принципов проектирования БД, имеет смысл вернуться к понятию "производный атрибут", введенному нами в Главе 7.
Основное правило, которого придерживаются проектировщики БД, состоит в том, что значение пересчитывается только тогда, когда в нем возникает необходимость. При этом нарушается другое правило - что атрибуты всегда становятся столбцами.
Но что делать в том случае, если к значению атрибута программы обращаются часто, а изменения происходят достаточно редко ? Необходимости в постоянном пересчете значения не будет, если мы создадим для производного атрибута столбец и будем корректировать его значение только тогда, когда оно изменится в действительности. Решающими условиями при выборе способа реализации, таким образом, станут:

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

существенность затрат по пересчету. Обычно это имеет место, когда пересчет затрагивает более одной строки БД.

Проверка полноты

Просмотрите всю документацию по существующей системе, все канцелярские формы, отчеты и т.п. Не удастся ли вам обнаружить такой элемент данных, который не является атрибутом и не может быть выведен из атрибутов, включенных в вашу модель, но должен быть охвачен? Добавьте в модель все обнаруженные сейчас, но пропущенные ранее атрибуты.
Распечатайте отчеты по CASE-проектированию и проверьте их вместе с вашими пользователями на предмет полноты.
Подготовьте проблемные представления для всех граничных сущностей. Соотносятся ли они с форматами существующих файлов? (См. Приложение G.)
Проверьте каждую элементарную функцию. Являются ли упоминаемые в ней сущности (явно или неявно - с помощью синонимов) известными вам? Не пропущены ли среди их атрибутов какие-нибудь логически связанные элементы данных? Нет ли каких-нибудь пропущенных связей?
Проверьте, не используются ли в функциональных блоках (иногда называемых "коммерческими единицами") какие-либо понятия, применимые только в определенных местах. Имеются ли данные об объемах информации, перерабатываемых функциональным блоком?

Реализация в базе данных

Рассмотрим в двух словах, как модель для сущностей КУПОН, МЕСТО и САМОЛЕТ может быть организована с помощью различных баз данных.
Реляционная база данных
В реляционной БД каждая сущность становится таблицей, а ее атрибуты - столбцами в таблице.
Рисунок 2-10. Реляционный проект

Столбцы с отметкой "**" используются для реализации связей между таблицами. Так, например, регистрационный номер самолета, включенный в таблицу SEAT, реализует связь между сущностями МЕСТО и САМОЛЕТ. Такой столбец именуют внешним ключом.
Выражение "not null" соответствует либо обязательной связи (которая на модели обозначается сплошной линией), либо обязательному атрибуту. Выражение "null" используется для обозначения либо необязательной связи (пунктирная линия), либо необязательного атрибута - "null" означает "значение может отсутствовать".
Сетевая база данных
В сетевой БД каждой сущности обычно соответствует запись. Каждой связи присваивается набор указателей NPO (Следующий, Предыдущий и Владелец). Записи, требующие доступа по ключу, располагаются с использованием алгоритма хэширования (CALC). Записи, которые на диске должны быть сгруппированы, требуют для своего размещения использования еще одной записи (VIA).
Символами "MA" на схеме обозначается обязательная автоматическая связь (Mandatory Automatic) - скажем, между записью "БИЛЕТ" и владельцем "САМОЛЕТ". Символы "OM" служат для обозначения необязательной связи.
Рисунок 2-11. Сетевой проект

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

Рисунок 2-12. Иерархический проект



Файл на языке КОБОЛ

Если используется алгоритмический язык КОБОЛ, запись САМОЛЕТ (AIRCRAFT) будет содержать повторяющуюся группу для сущности МЕСТО (SEAT):

Рисунок 2-13. Расположение полей в записи на КОБОЛе



Файл с ручной обработкой

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

Рисунок 2-14. Регистрационный шкаф

Регистрация изменений (в прошлом и будущем)

Природа атрибута может со временем меняться; например, состояние контракта. Если принять во внимание время, можно найти такие значения атрибутов, которые характеризуют вхождение сущности на протяжении перекрывающихся интервалов времени; например, имена или псевдонимы личности. Связь также в то или иное время может относиться к разным вхождениям сущности; например, место жительства личности.
Все подобные проблемы решаются одинаково, а именно путем создания новой сущности, значениям которой соответствует интервал времени, когда они имеют место.
Изменение значений атрибутов
Рисунок 8-11. Атрибут "статус" становится сущностью

Если рассматривать СТАТУС в качестве уникального идентификатора, возникает несколько вопросов; например:
"Может ли контракт в течение одного дня находиться более чем в одном состоянии?"
Рисунок 8-12. Атрибут "фамилия" становится сущностью

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

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

Рекурсивные связи

Многие к одному
Рисунок B-11. Обязательность на одном конце с необязательностью на другом

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

В принципе невозможна.
Рисунок B-13. Необязательность на одном конце с обязательностью на другом

В принципе невозможна.
Рисунок B-14. Необязательность на обоих концах

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

В принципе невозможна.
Рисунок B-16. Обязательность на обоих концах

В принципе невозможна.
Рисунок B-17. Необязательность на обоих концах

Редко, но имеет место. Отражает связи альтернативного типа.
Многие ко многим
Рисунок B-18. Необязательность на обоих концах

Имеет место на ранних этапах. Часто отражает структуру "перечня материалов" (взаимная вложенность компонент).
Пример:
Каждая КОМПОНЕНТА может состоять из одной и более (других) КОМПОНЕНТ и каждая КОМПОНЕНТА может использоваться в одной и более (других) КОМПОНЕНТАХ.
Рисунок B-19. Обязательность на одном конце с необязательностью на другом

В принципе невозможна.
Рисунок B-20. Обязательность на обоих концах

В принципе невозможна.

Сети

Сетевая структура очень часто имеет место на схемах взаимосвязей между сущностями.
Рисунок 8-9. Сетевая структура

В нашей структуре просматривается множество иерархий:

E/D/B/A

E/D/C/A

E/D/C/B/A

E/A

Каждая из иерархий связывает сущности E и A в сложную сеть, и можно пройти по всем путям, соединяющим экземпляры (вхождения) этих сущностей. Начиная с E, прямо перейдем ко всем вхождениям сущности A, для каждого из них найдем соответствующее C, а затем D и E.

Шаг 1		начать с E
Шаг 2		выбрать все непосредственно связанные A
Шаг 3		для каждого A выбрать соответствующее C и соответствующее тому D и соответствующее тому E (с этой точки вы можете перезапустить шаг 1)
Шаг 4		также для каждого A выбрать соответствующее B, для которого либо выбрать соответствующее ему D и соответствующее тому E (еще одна точка рестарта)
Шаг 5		либо выбрать соответствующее ему C и соответствующее тому D и соответствующее тому E (последняя точка рестарта)

Рисунок 8-10. Элементарный пример сетевой структуры

Рассматривая этот пример, можно начать со служащего и найти ту организационную единицу, в которой этот служащий работает ныне, а затем отыскать того служащего, который этой организационной единицей в настоящее время руководит.
Если организационной единицей является отдел, можно найти ту организационную единицу, куда этот отдел ныне входит, и ее руководителя (и т.д. вверх по организационной иерархии). Ясно отсюда, что такую сеть можно использовать для всех случаев, когда нам нужно узнать, кто где работает.
Замечание: модель не учитывает многих обстоятельств, ибо не позволяет служащему работать более, чем в одном отделе, не запоминает перестановок (невосприимчива к изменениям), не допускает совмещения постов руководителей нескольких компаний или отделов и т.д.
Еще один интересный логический момент заключается в том, что вхождение сущности "организационная единица" не может существовать без служащего, руководящего его работой. И наоборот, вхождение сущности "служащий" не может существовать, если нет такой организационной единицы, которая была бы местом его работы. Ситуация, похожая на "курицу и яйцо" - что раньше?
Чтобы усовершенствовать эту модель, нам потребуются знания.

Схемная архитектура

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

Следующие шаги

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

Сущность

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

Изображение сущности
На схемах сущность изображается в виде блока (прямоугольника с закругленными углами) с именем в середине. Именем может быть существительное единственного числа, записываемое заглавными буквами.
Блок может иметь любой размер и форму, так чтобы в нем могло уместиться точно выраженное имя сущности (старайтесь избегать сокращений), а также чтобы повысить читабельность схемы. Иногда, например, имеет смысл придавать блокам вытянутую форму, чтобы избегать пересечения линий связи на схеме.
Имена сущностей
Имя сущности может представлять тип или класс объекта, но не конкретное значение. В нашем примере именем сущности не могут стать ни "Хитроу", ни "Джон Ф. Кеннеди" - конкретные значения сущности АЭРОПОРТ.
В тех случаях, когда для именования сущности подходят разные слова, имеющие идентичный смысл в контексте данной проблемы, допускается использование синонимов. Одно имя назначается в качестве первого; синонимы могут записываться заглавными буквами с символом "наклонная черта" (/) перед каждым. Для облегчения понимания понятия и его отличий от других подобных понятий могут использоваться примеры.
Рисунок 3-2. Пример сущности

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

...ВЕРТОЛЕТ, который является разновидностью САМОЛЕТА, ...

Если сущность является и супертипом, и подтипом одновременно, используйте обе фразы:

...АЭРОПЛАН, который является разновидностью САМОЛЕТА и должен быть либо ПЛАНЕРОМ, либо УПРАВЛЯЕМЫМ АЭРОПЛАНОМ, ...

Проверка правильности задания подтипа

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

Инвертированный синтаксис

Запишем утверждение наоборот, например:

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

Установление различий между подтипами

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

На уровне реализации добавляется новый элемент данных, которому присваиваются значения, допустимые для каждого из возможных подтипов. Этот элемент данных можно назвать, например, ПОДТИП СУЩНОСТИ (в нашем случае ПОДТИП САМОЛЕТА).

На прикладном уровне вы можете завести атрибут, использующийся для той же цели. Так, например, атрибут "пол" со значениями "мужской" и "женский" дает нам два подтипа сущности ЛИЧНОСТЬ.

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

Так, например, сущность ЗАКАЗ может иметь следующие три подтипа:

Подтип	Описание условий и/или значений
ОЖИДАЕМЫЙ ЗАКАЗ	где индикатор подтверждения = no
ПОДТВЕРЖДЕННЫЙ ЗАКАЗ	где индикатор подтверждения = yes И дата выполнения неизвестна или находится в будущем
ВЫПОЛНЕННЫЙ ЗАКАЗ	где дата выполнения известна И = текущей или находится в прошлом

Пересечение подтипов. (Ортогональные подтипы)

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


Это имеет смысл тогда, когда сущность может играть несколько ролей; например, такие сущности, как ЛИЧНОСТЬ или ОРГАНИЗАЦИОННАЯ ЕДИНИЦА.

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

Так, например, две совокупности подтипов для сущности ЛИЧНОСТЬ именуются ВИД ЗАНЯТОСТИ и ПОЛ.

Вхождение сущности ЛИЧНОСТЬ, идентифицируемое как СОСТОЯЩАЯ НА СЛУЖБЕ, имеет даты начала и окончания службы. ЛИЧНОСТЬ, идентифицируемая как ИСПОЛНЯЮЩАЯ ЗАКАЗЫ, имеет связь с ЗАКАЗЫВАЮЩЕЙ ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ, которая нанимает ее. Поскольку у нас возникают пересекающиеся подтипы, было бы удобнее каждой из совокупностей присвоить наименование. В нашем примере мы выбрали наименование ВИД ЗАНЯТОСТИ.

Рисунок 7-2. Совокупность подтипов ВИД ЗАНЯТОСТИ



В зависимости от значения атрибута "пол" вхождение сущности ЛИЧНОСТЬ относится к подтипу МУЖЧИНА или ЖЕНЩИНА. Для удобства этой совокупности подтипов присвоено наименование ПОЛ.

Рисунок 7-3. Совокупность подтипов ПОЛ



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

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

Функция "Создать вхождение с именем ИСПОЛНЯЮЩАЯ ЗАКАЗЫ" подразумевает инициализацию всех атрибутов, описанных для данного подтипа, а также всех атрибутов, унаследованных им от сущности ЛИЧНОСТЬ. Мы должны также предусмотреть связь с ЗАКАЗЫВАЮЩЕЙ ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕЙ, которая нанимает ИСПОЛНЯЮЩУЮ ЗАКАЗЫ. Кроме того, у этого подтипа отсутствует атрибут "дата начала службы": этот атрибут присущ только подтипу СОСТОЯЩАЯ НА СЛУЖБЕ.

Справочная сущность

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


Сущности, описывающие тип объекта (например, ТИП САМОЛЕТА), зачастую выступают в качестве справочных сущностей, так же как и сущности, подобные ОРГАНИЗАЦИОННОЙ ЕДИНИЦЕ и ЛИЧНОСТИ. Вхождения справочной сущности могут существовать самостоятельно, безотносительно к другим объектам.

Граничная сущность

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

Рисунок 7-4. Справочные и граничная сущности



Определение сущности

Для того, чтобы считать анализ информационного содержимого сущности завершенным, мы должны иметь следующее:

имя

множественное число

синонимы

объемы и, если возможно, темпы роста

описание

примечания/замечания,

а также все, что связано с этой сущностью:

атрибуты (по меньшей мере два)

связи (как минимум одну)

уникальный идентификатор (как минимум один)

функции, с которыми она связана (как минимум одна).

Полностью определение сущности описано в Приложении C.

Требования к распределенной обработке

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

Детализация определения

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

Связь между сущностями

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

именем

степенью / мощностью

признаком обязательности.

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

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

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

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

Каждая СУЩНОСТЬ-A должна "описание-связи-1" одну и только одну СУЩНОСТЬ-B

а справа налево:

Каждая СУЩНОСТЬ-B может "описание-связи-2" одну и более СУЩНОСТЕЙ-A.

Все это может выглядеть несколько непонятно до тех пор, пока вы не обратитесь к реальному примеру:

Рисунок 3-6. Пример связи



Каждый БИЛЕТ должен предназначаться для одного и только одного ПАССАЖИРА и:

Каждый ПАССАЖИР может быть указан на одном и более БИЛЕТАХ.

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

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

Дисциплина идентификации

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

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

Формальный синтаксис

Для чтения любой связи используется следующий синтаксис:



Фразы "и любая" и "всегда" добавляются для придания утверждению большей строгости. Фраза "не так ли?" добавляется для проверки утверждения.

Если мы прочитаем связь БИЛЕТ/ПАССАЖИР снова, она станет яснее.

Каждый и любой БИЛЕТ должен предназначаться для одного и только одного ПАССАЖИРА всегда, не так ли ?

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


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

Инвертированный синтаксис

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

Рисунок 3-7.



При использовании нормального синтаксиса связь читается так:

Каждый КУПОН должен оформляться на один и только один РЕЙС.

При использовании инвертированного синтаксиса:

Это означает, что вы не можете иметь КУПОН, которому бы не соответствовал уникально определенный РЕЙС, не так ли?

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

Вопрос и здесь получился корректным, ибо в модели не допускается использование КУПОНА, которому бы не соответствовал определенный рейс на определенную дату. Однако в реальной жизни существуют билеты с открытой датой, у которых купоны не содержат точную дату вылета, поэтому характеристику связи необходимо изменить на "необязательную".

Разрешенные связи

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

Рисунок 3-8. Разрешенные формы связей



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

Рисунок 3-9.Неразрешенные формы связей



Дополнительные соглашения и правила, касающиеся связей, рассматриваются в главе 7. Исчерпывающий перечень разрешенных и неразрешенных форм связей приводится в Приложении B.

Связи

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

Вновь созданная сущность должна иметь имя; зачастую при выборе имени используются описания подлежащей разделению связи. Как вы поняли, построенная модель позволяет следить за обслуживанием самолетов. Атрибуты новой сущности и ее связи с другими сущностями добавляются по известной схеме.
Понятие исключительности
Две и более связей, в которых принимает участие одна и та же сущность, могут быть взаимно исключающими.
Представление
На схеме исключительность обозначается дугой, пересекающей каждую из взаимно исключающих связей данной сущности, с выделением места пересечения.
Рисунок 7-6. Исключающая дуга

Место пересечения может быть жирно обведено, и тогда простое пересечение дугой одной из линий связи будет говорить о том, что эта связь не вступает с другими связями, пересеченными той же дугой, в отношение взаимного исключения. Другой способ представления показан на Рисунке 7-8.
Рисунок 7-8

Если с одной и той же сущностью связано несколько исключающих дуг, для наглядности представления изображайте их на расстоянии друг от друга (Рисунок 7-9).
Правила

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

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

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

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

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

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

Проиллюстрируем некоторые из правил с помощью рисунка:

Рисунок 7-9.



Синтаксис

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



Рисунок 7-10. Реальный пример с исключающей дугой



Каждый КУПОН должен оформляться на один и только один РЕЙС (на конкретную дату) или быть открытым для одного и только одного АВИАМАРШРУТА (идентифицируемого номером рейса, но не датой, т.е. имеет место открытый купон/билет).

Обратный синтаксис

Используя обратный синтаксис, получаем:

Это означает, что у нас никогда не может быть КУПОНА, не оформленного на конкретный РЕЙС (с конкретной датой) и в то же время не открытого для СТАНДАРТНОГО РЕЙСА (с номером). Так ли это?

Обратите внимание на то, что мы воспользовались именами атрибутов (дабы придать информации большую определенность).

Недопустимые комбинации

Рисунок 7-11. Дуги, изображенные с нарушением правил



Каждая из изображенных дуг не проходит логическую проверку.

Необычные дуги

Рисунок 7-12. Дуга на конце связи со степенью "один"



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

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

Непереносимые связи

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


Если это не допускается, значит связь является непереносимой.

Представление

Непереносимая связь обозначается значком <>, изображаемым на соответствующем конце.

Рисунок 7-13. Пример



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

Синтаксис

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

Каждый КУПОН должен входить в один и только один БИЛЕТ и никогда не может быть перенесен в другой БИЛЕТ.

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

Оценка степени мощности связи

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

Представление

При указании степени мощности используйте символы =, >, >=, <, <=.

Рисунок 7-14. Пример 1



Каждый ГОД может включать в себя от одного до двенадцати МЕСЯЦЕВ.

Рисунок 7-15. Пример 2



Каждый СЧЕТ должен принадлежать одной или двум ЛИЧНОСТЯМ. (Т.е. разрешаются общие счета.)

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

Рисунок 7-16. Пример 3



Рисунок 7-17. Диаграмма распределения



Вершины на диаграмме соответствуют:

обычным счетам

счетам с отсроченными платежами

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

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

Определение связи

Для того, чтобы считать анализ информационного содержимого связи завершенным, мы должны иметь следующее:

степень (мощность)

описание

обязательность (по возможности с оценкой)

замечания

а также все, что сопутствующее этой связи:

сущности (ровно две)

дуги (не более одной)

уникальные идентификаторы

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

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

Избыточная связь

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

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

Рисунок 7-18. Пример



На первый взгляд схема представляется правдоподобной и действительно отражает структуру некоторых купонов; тем не менее, связь между КУПОНОМ и РЕЙСОМ уже недвусмысленно идентифицирует как АВИАМАРШРУТ, так и АВИАЛИНИЮ, делая тем самым две другие связи сущности КУПОН избыточными.

Каскадное удаление

В реальной жизни, если мы напрочь забываем о чем-то, то мы забываем тем самым и о всех связанных с этим вещах.

Так, например, если вы удаляете все связанное с БИЛЕТОМ, вы удалите тем самым и все связанное с КУПОНОМ. КУПОНЫ (потомки) существуют только в контексте БИЛЕТА (родительской сущности).

Такое действие называется "каскадным удалением" и имеет отношение к сущностям, имеющим потомков и связи типа "многие".

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

Так, например, нельзя удалить сущность ЭКИПАЖ до тех пор, пока в нем есть какие-то ЧЛЕНЫ.

Признак каскадного удаления

Статус каскадного удаления отражается с помощью специального признака:

X = Удалить всех потомков, если удаляется родитель

C = Помешать удалению родителя в случае существования хотя бы одного потомка

N = Родитель и потомок удаляются отдельно друг от друга.

Признак имеет значение C обычно тогда, когда потомок связан с родителем обязательной связью (must be).

Значение N свидетельствует о том, что связь является необязательной с обеих сторон.

Каскадная коррекция

Относится только к уровню реализации проекта и используется только при наличии системы управления реляционной БД (СУРБД). При изменении значения уникального идентификатора/первичного ключа родителя, новое значение автоматически заносится во все внешние ключи.

Каскадное удаление и коррекция успешно реализуются с помощью СУРБД и генераторов прикладных программ.

Терминология

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

Тип и вхождение

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

Эту схему можно представить в трехмерном пространстве и рассмотреть конкретные вхождения сущностей.
Рисунок 3-20

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

Теперь мы имеем на сотни тысяч больше купонов, из которых мы выбрали те, которые когда-либо (в прошлом, настоящем или будущем) оформлялись на место A1 на самолете с регистрационным номером G-ORCE.
Под ваши определения в каждом конкретном случае должен точно подходить каждый экземпляр (вхождение) определяемого объекта. В нашем примере эскадрилья может включать в себя пару очень старых самолетов, относительно которых нас может чрезвычайно интересовать, когда в последний раз проверялось наличие запчастей для них. Для таких исключительных случаев, при необходимости, определение может включать в себя информацию, присутствующую как "возможность" и не требующуюся в обычных случаях.
Все прочие понятия и определения в МВМС также адресуются к типу или классу объекта.

Типология сущностей

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

Сущность A имеет три взаимно исключающих друг друга подтипа: A1, A2 и A3. Это довольно укрупненное разделение, поскольку в нем допускается не более трех подтипов, однако оно позволяет задавать атрибуты и связи, присущие отдельным подтипам.
Рисунок 8-20. Атрибут "тип"

Подход, идентичный классификации и допустимый во многих простых ситуациях.
Рисунок 8-21. Сущность "тип"

Более общая конструкция.
Рисунок 8-22. Множественность типов

Схема аналогична классификации. Отличается наибольшей гибкостью и может использоваться в очень сложных моделях.

Участие руководства

Правильно понимаемое МВМС концентрируется на информации, жизненно важной для данной организации. Это либо массовая информация (как купоны), либо имеющая критическое значение (связанная с формированием экипажей и контролем безопасности). Руководство сильно интересуют детальные сведения по таким направлениям, которые оказывают наибольшее влияние на управление. И вам поэтому следует получить "добро" на всестороннюю проверку модели с привлечением ответственных должностных лиц, действительно разбирающихся в деловых вопросах. Им должна быть дана возможность направлять ваши усилия в нужное русло.
Но не следует показывать им всю схему целиком.
Возводите модель осторожно, используя элементы, иллюстрирующие их понимание дела. Прибегайте к тематическим примерам, понятным для них, обращайте внимание на текущие вопросы, которые они решают, демонстрируя при этом, каким образом новая модель может оказать им помощь в их проблемах. Так, только для компании "Atlantis Airline Flights" может потребоваться от тридцати до сорока подсхем, иллюстрирующих ее деятельность до подробностей.
Построенная и согласованная модель взаимосвязей между сущностями имеет сразу несколько назначений. Во-первых, она образует архитектурный каркас, необходимый для разработки новых и совершенствования существующих систем. Во-вторых, она дает представление о проекте БД "в первом разрезе". Но и это еще не все. В передовых компаниях она используется и на уровне высшего руководства в качестве катализатора, дающего толчок к рождению новых идей.

Уникальный идентификатор

Каждая сущность должна иметь уникальное определение, которое обеспечивается с помощью комбинации атрибутов и/или связей. Поэтому всегда следует искать дополнительные атрибуты, помогающие идентифицировать сущность.
Для самолета в таком случае могут иметь значение и номера шасси, и номера двигателей и т.п.
Значение атрибута должно зависеть от всего уникального идентификатора.
Уберите те из атрибутов, значения которых зависят только от одной составляющей уникального идентификатора. Эти действия называют "Второй формой нормализации" (см. Приложение A). Подобные атрибуты обычно указывают на отсутствие какой-либо сущности.
Атрибуты должны зависеть от значения уникального идентификатора
Уберите те из атрибутов, которые не зависят от значения уникального идентификатора сущности (т.н. "Третья форма нормализации"). Так, например, на посадочном талоне может быть записано имя пассажира. Но:
"Зависит ли имя пассажира как-нибудь от значения уникального идентификатора посадочного талона?"
Очевидно, нет. (Не должен же я менять свое имя при выписке посадочного талона!) Если атрибут не зависит от значения уникального идентификатора, значит, возможно, нами не учтена какая-либо сущность и/или связь.
Необязательные атрибуты
Значения некоторых атрибутов могут в какие-то моменты просто отсутствовать или же быть недоступны. В таких случаях перед именем атрибута на схеме ставится буква "o", что говорит о том, что атрибут - необязательный (optional).
Обязательные атрибуты
Те атрибуты, значения которых должны быть известны всегда, имеют перед своим именем значок "*". Но будьте внимательны - добавленное вами условие будет означать, что вам не известен случай появления такого экземпляра сущности, который не имел бы значений своих обязательных атрибутов. Вот то, что я называю настоящей строгостью! На практике же уровень строгости соглашений обычно слегка смягчается.
Рисунок 3-17. Изображение необязательности атрибутов

Определение уникального идентификатора

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

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

Рисунок 3-18. Изображение уникальных идентификаторов



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

связь с местом и, благодаря этому, с его номером;

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

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

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

Управленческая функция/процесс

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

Управленческое событие

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

Управление

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

доступом к определениям

полномочиями на внесение изменений

описанием системы

внесением изменений и формированием новых версий.

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

Упрощенный подход к проектированию

Шаг 1
Каждая элементарная сущность преобразуется (транслируется) в таблицу. Элементарной называется сущность, не являющаяся подтипом. Таблице обычно дается имя, представляющее собой множественную форму имени сущности.
Шаг 2
Каждый атрибут превращается в одноименный столбец, при этом формат его подвергается уточнению.
Необязательные атрибуты становятся столбцами с разрешением пустого (null) значения. Обязательные атрибуты становятся столбцами типа not-null (ненулевыми).
Шаг 3
Компоненты уникального идентификатора сущности становятся первичным ключом таблицы. Заметим, что сущность может иметь несколько уникальных идентификаторов, тогда из них выбирается тот, который используется наиболее часто.
Напомним также, что сущность уникально идентифицируется комбинацией атрибутов и/или связей. Связи преобразуются следующим образом: в качестве первичного ключа используются компоненты уникального идентификатора сущности на дальнем конце связи (процедура их поиска продолжается рекурсивно, пока наконец не будут найдены атрибуты).
При этом описания связей и/или имена сущностей добавляются к наименованиям атрибутов в целях обеспечения уникальности имени столбца, который предполагается использовать в качестве компоненты внешнего ключа.
Шаг 4
Связи типа "многие к одному" (и "один к одному") становятся внешними ключами. При этом в качестве столбцов используются уникальные идентификаторы сущностей на конце "один".
Необязательные связи создают столбцы с разрешением пустого (null) значения. Обязательные связи создают столбцы типа not-null (ненулевые).
Рисунок F-1. Пример

Шаги 1-4 годятся для большинства несложных проектов. Прежде чем мы переходить к более сложным случаям, предполагающим использование исключающих дуг и подтипов, рассмотрим кратко, как создаются индексы.
Шаг 5. Проектирование индексов
Индексы создаются для:

первичного ключа (уникальный индекс)

внешних ключей и

индексы, предусмотренные матрицей функция/атрибут.

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

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

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

Последующее слежение за работой СУРБД позволит определить, какие индексы и при каких обстоятельствах используются.

Пример

Для трех вышеназванных таблиц можно выбрать следующие индексы:

Код в AIRPORTS	(Уникальный индекс)
Код в AIRLINES	(Уникальный индекс)
Код родительской авиалинии в AIRLINES	(Неуникальный индекс)
Номер рейса и Код авиалинии в AIRLINE ROUTES	(Составной уникальный индекс)
Код аэропорта вылета в AIRLINE ROUTES	(Неуникальный индекс)
Код аэропорта назначения в AIRLINE ROUTES	(Неуникальный индекс)

Шаг 6. Проектирование подтипов

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

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

Существует два основных варианта представления подтипов (каждая из которых имеет свои преимущества и недостатки):

все подтипы в одной таблице

таблица для каждого подтипа.

Все подтипы в одной таблице

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

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


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

Все это имеет отношение к каждому подтипу, к каждому подтипу данного подтипа и т.п. Разница в том, что все столбцы, создаваемые для подтипов, имеют тип null (необязательность). Обязательный атрибут (или связь) для одного подтипа не должен использоваться для другого - таким образом, все они должны быть необязательными, целостность же обеспечивается либо прикладными программными средствами, либо через обзор с опцией контроля (check option).

В таблицу должен быть добавлен по меньшей мере еще один ненулевой столбец, обозначающий тип (TYPE) и включаемый в первичный ключ.

Например:

TYPE

char

4

not null

с предписанным значением для каждого подтипа

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

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

Рисунок F-2. Пример



Обратите внимание на то, что два столбца именуются "Номер...", при этом имя столбца содержит имя сущности, уточняющее его смысл. Кроме того, столбцы "Количество" и "Код_продукта" сделаны необязательными, поскольку ни один из них не связан с ПРОЧЕЙ СТРОКОЙ ЗАКАЗА.

Столбец "Тип" добавлен, чтобы иметь возможность различать подтипы сущности СТРОКА ЗАКАЗА.


При этом код "СОП" означает СТРОКУ, ОПИСЫВАЮЩУЮ ПРОДУКТ, а "ПС" - ПРОЧУЮ СТРОКУ.

Описание реляционных обзоров на языке SQL:

       CREATE VIEW   OTHER_ORDER_LINES AS    /* обзор ПРОЧИЕ_СТРОКИ_                                                 ЗАКАЗА */        SELECT LINE_NUMBER,                   /* номер строки */               ORDER_NUMBER,                  /* номер заказа */               DESCRIPTION,                   /* описание */               TAX_COMMENT,                   /* комментарии */               TYPE                           /* тип */        FROM   ORDER_LINES                    /* таблица                                                 СТРОКИ_ЗАКАЗА */        WHERE  TYPE='OOL'                     /* ТИП='ПС' */        WITH CHECK OPTION                CREATE VIEW   PRODUCT_ORDER_LINE AS   /* обзор СТРОКА_                                                 ОПИСЫВАЮЩАЯ_ПРОДУКТ */        SELECT LINE_NUMBER,                   /* номер строки */               ORDER_NUMBER,                  /* номер заказа */               DESCRIPTION,                   /* описание */               QUANTITY,                      /* количество */               PRODUCT_CODE,                  /* код продукта */               TYPE                           /* тип */        FROM   ORDER_LINES                    /* таблица                                                 СТРОКИ_ЗАКАЗА */        WHERE  TYPE='OOL'                     /* ТИП='СОП' */        AND    QUANTITY NOT NULL        AND    EXISTS        (SELECT NULL FROM PRODUCTS WHERE      /* таблица ПРОДУКТЫ */        PRODUCTS.CODE=ORDER_LINES.PRODUCT_CODE)        WITH CHECK OPTION

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

Таблица для одного подтипа

Таблицы, создаваемые для отдельных подтипов, должны учитывать все возможные вхождения.


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

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

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

При работе с супертипом вам может также пригодиться обзор типа UNION.

Рисунок F-3. Пример



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



Рассмотрим обзор для подтипа E:

                CREATE VIEW    E AS        SELECT         e,                       b1,                       b2,                       a1,                       G_g,                       type,                       a2,                       parent_a1,                       parent_G_g,                       parent_type        FROM           B        WHERE     type='E'        AND       e not null        AND       EXISTS        (SELECT NULL FROM B        WHERE     B.a1 = E.Parent_a1        AND       B.G_g = E.Parent_G_g        AND       B.Type = E.Parent_Type)        WITH CHECK OPTION                И для полноты впечатления рассмотрим обзор типа UNION для A:                CREATE VIEW    A AS        SELECT    * FROM B        UNION        SELECT    * FROM C                Символ * в операторе SELECT означает выборку всех столбцов.

Преимущества и недостатки

Все подтипы в одной таблице	Таблица для одного подтипа
Преимущества	Преимущества
Все в одном месте	Совокупность условий более наглядно распределяется по подтипам
Простота доступа к супертипу и подтипам	Программы имеют дело только с теми таблицами, которые связаны с интересующими нас подтипами
Требуется меньше таблиц
Недостатки	Недостатки
Чересчур высокий уровень обобщения	Много дополнительных таблиц
Трудность объединения различных наборов столбцов с различной целостностью	Беспорядочное объединение столбцов в обзоре типа UNION
Возможны "узкие места", в частности при использовании механизмов блокировки	Проблемы с быстродействием при обработке обзора типа UNION
Столбцы для подтипов должны стать необязательными	Коррекция супертипа невозможна, что мешает выполнению функций
В некоторых СУРБД возникает опасность превышения допустимого количества столбцов или выхода за пределы отведенного пространства (за счет хранения пустых значений)

<


Шаг 7. Исключающая связь

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

общий домен

заданные явно внешние ключи.

Общий домен

Если оставшиеся внешние ключи можно включить в один домен (идентичный формат), создайте два столбца:

Идентификатор связи

Идентификатор сущности.

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

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

Рисунок F-4. Пример



В таблице TIMESHEET_ENTRIES (СТРОКИ_ТАБЕЛЯ) связи "по ЭТАПУ ПРОЕКТИРОВАНИЯ" и "о ДЕЯТЕЛЬНОСТИ ВНЕ ПРОЕКТА" реализуются с помощью столбцов:

Строка_табеля_по (Timesheet_for)	char	3	not null	(значение 'ЭП' и 'ДВП')
Код_деятельности (Activity_code)	char	7	not null

Обратите внимание на развернутость имен, присвоенных столбцам. Значение "кода_деятельности" равно коду либо ЭТАПА ПРОЕКТИРОВАНИЯ, либо ДЕЯТЕЛЬНОСТИ ВНЕ ПРОЕКТА. Поскольку связи являются обязательными, столбцы имеют тип not null.

Явное задание внешних ключей

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

Вернемся к нашему примеру, но на этот раз предположим, что код этапа проектирования является целым числом (integer).

Рисунок F-5. Снова предыдущий пример



В результате добавятся столбцы:

Код_этапа_проектирования (Project_units_code)	integer	5	null
Код_деятельности_вне_проекта Non-project_activities_code)	char	7	null

Преимущества и недостатки

Общий домен	Явное задание внешних ключей
Преимущества	Преимущества
Используются только два столбца Необязательность поддерживается средствами СУРБД	Видны условия соединения
Недостатки	Недостатки
Оба столбца должны использоваться во всех операциях соединения	Дополнительные столбцы Необязательность столбцов и их использование реализуются прикладными средствами

В чем заключается значимость МВМС?

За последние двадцать лет компьютерные системы усложнились чрезвычайно. Они претерпели ряд эволюций:

опытные разработки (экспериментирование);

отдельные функциональные системы;

ведомственные системы (в рамках отдела);

интегрированные операционные системы;

системы автоматизации делопроизводства;

административные информационные системы.

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

Связь с циклом проектирования системы
В применении к циклу проектирования управленческой системы можно сказать, что вопросы, рассматриваемые в данной книге, имеют отношение к этапам выработки стратегии и анализа. Принципы, изложенные здесь, имеют более широкое значение - они применимы на этапе проектирования БД и на этапе запуска в эксплуатацию. Более подробно о цикле проектирования см. в документе "CASE*Method - Tasks and Deliverables".

Внешняя схема

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

К обсуждению вопросов проектирования высшее

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

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

Мы рассмотрели некоторые важные дополнительные соглашения и определения, в частности:

подтипы и супертипы

исключающие связи

непереносимые связи.

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

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

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

Зависимость данных

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

Вернувшись к нашим авиалиниям, предположим, что исходная (традиционная) система составления расписания рейсов не в состоянии дальше справляться с увеличением траффика и требует скорейшей автоматизации. После проведения последней мы добавим в систему элементы отслеживания билетов и купонов.
Правила
Из приведенной схемы видно, что реализация сущности РЕЙС требует учета соответствующих деталей сущностей САМОЛЕТ, АВИАМАРШРУТ, АВИАЛИНИЯ и АЭРОПОРТ. Подобную зависимость легко установить, если пройтись по обязательным связям (типа "должен"); например: РЕЙС должен выполняться по АВИАМАРШРУТУ.
Мы также добавим сюда сущности, связанные с текущей сущностью отношением типа "многие (или один) к одному"; так, например, на РЕЙС может назначаться САМОЛЕТ. В этом случае принимаются во внимание как обязательные, так и необязательные связи.
Те же правила касаются и сущностей, выполняющих в цепочке роль последующих звеньев.
Переходя впоследствии к реализации сущности БИЛЕТ, мы должны будем учесть детали не только сущности ПАССАЖИР, но и сущности КУПОН, поскольку БИЛЕТ должен состоять из одного и более КУПОНОВ. Следуя тем же правилам, мы должны также учесть все связи, предполагаемые сущностью КУПОН, а именно: с РЕЙСОМ, САМОЛЕТОМ (необязательная), АВИАМАРШРУТОМ, АЭРОПОРТОМ(из), АЭРОПОРТОМ(в), АВИАЛИНИЕЙ, МЕСТОМ (необязательная) и вновь с САМОЛЕТОМ (но уже через место, необязательная). Такую зависимость легко обнаружить, имея полное проблемное представление сущности КУПОН.
Дальнейшие действия
Затем мы можем принять во внимание все прикладные функции, имеющие отношение к отобранным сущностям, или их проблемные представления, и отобрать те из них, что могут составить основу поэтапного совершенствования модели в направлении более полного удовлетворения пользовательских запросов, целей и приоритетов.
Обращение к важнейшим проблемным представлениям уточняет зависимость, обнаруженную между данными.



    Инновации: Менеджмент - Моделирование - Софт

• Инновационный менеджмент
  
• Разработка программного обеспечения
  
• Россия и инновации
  
• Управление инновационным менеджментом
  
  
• Моделирование
  
• Финансовое моделирование
  
• Системы моделирования
  
• Виды моделирования
  
• Практическое моделирование
  
  
• Пакет Mechanical Desktop
  
• Моделирование программ
  
  
• Софт для моделирования
  
• Пакет Simulink
  
• Моделирование в IBM
  
• MSC Nastran Моделирование -
  
• AutoCAD
  
  
• Unigraphics
  
• P-CAD