Альтернативные модели сущностей и их отражение в проекте
Рассмотренные соглашения по моделированию не исключают применение различных способов построения моделей. Рассмотрим три таких альтернативных способа с точки зрения их реализации в проекте.
Рисунок 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)
не является ли связь переносимой?
заданы ли степень связи и обязательность для каждой стороны?
допустима ли конструкция связи? Пример недопустимой конструкции:
не относится ли ее конструкция к редко используемым (типа "один к одному" или "многие ко многим")?
не является ли она избыточной?
не изменяется ли она с течением времени?
если связь обязательная, всегда ли она отражает отношение к сущности, представляющей противоположную сторону?
Для исключающей связи:
все ли концы связей, покрываемые исключающей дугой, имеют один и тот же тип обязательности?
все ли из них относятся к одной и той же сущности?
обычно дуги пересекают разветвляющиеся концы - что вы можете сказать о данном случае?
связь может покрываться только одной дугой
все ли концы связей, покрываемые дугой, входят в уникальный идентификатор?
Как показывать модель пользователю
Такие модели могут представляться очень сложными и трудновоспринимаемыми для неподготовленного глаза. Прежде чем показывать их конечному пользователю, подготовьте подсхему, отражающую его конкретную область знаний и все, что ее непосредственно окружает.
Разбейте картину на отдельные фрагменты, которые пользователю будет легче воспринять, прежде чем он увидит целое. В этих главах мы постепенно вводили новые понятия и дополняли модель по шагам, тут же обсуждая каждое дополнение. Во многих случаях мы намеренно опускали ранее рассмотренную информацию, чтобы сконцентрироваться на новом понятии. Используйте этот подход при общении с пользователем - они оценят ваше усердие и помогут сделать модель адекватной за более короткое время.
Какие же цели преследует МВМС?
Вот они:
создание тщательно выверенной модели информационных потоков в организации, модели, служащей фундаментом для разработки новых и совершенствования существующих систем;
создание модели, инвариантной к способу хранения данных и методу доступа к ним; закладывание основ для принятия решений по поводу реализации проекта и обеспечения совместимости с существующими системами.
Классификации и категории
Мы все любим присваивать вещам ярлыки. К сожалению, мы редко пользуемся при этом взаимно исключающими понятиями и классифицируем объекты в лучшем случае по одному признаку. Для того, чтобы система стала гибкой, необходимо, чтобы ключевые сущности можно было классифицировать по стольким признакам, сколько требуется в тот или иной момент в интересах дела. Как изложить этот вопрос в общем виде?
Рисунок 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)
Система управления реляционной базой данных
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Описания/замечания Определяет состояние купона с точки зрения его анализа |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Обязательный/необязательный
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Форма |
Группа |
Проект |
Аналитик |
Дата |
Лист... |
|
C9 |
Пользователь |
Действие |
Проверил |
Дата |
Всего... |
