Пример er-диаграммы
На
диаграмме есть класс сущностей,
представляющий сотрудников компании.
Поскольку
некоторые сотрудники являются инженерами,
сущность СОТРУДНИК
связана с сущностью ИНЖЕНЕР как подтип. Каждый инженер должен быть сотрудником; сущность ИНЖЕНЕР имеет связь 1:1 с сущностью ГРУЗОВИК; каждый грузовик должен быть закреплен за каким-то инженером, но не у всех инженеров есть грузовики.
Инженеры выполняют работы (сущность РАБОТА) для клиентов (сущность КЛИЕНТ). Инженер может не выполнять никаких работ (иначе говоря, выполнять ноль работ) или выполнять много работ, но каждая отдельно взятая работа может выполняться только одним конкретным инженером. Для одного и того же клиента может выполняться много различных работ, и один и тот же вид работы может выполняться для множества клиентов. Клиент должен оплатить как минимум одну работу, но различные виды работ существуют независимо от клиентов. Связь КЛИЕНТ-РАБОТА имеет атрибут Плата, который показывает сумму, уплаченную конкретным клиентом за конкретную работу. (Прочие атрибуты сущностей и связей не показаны на этой диаграмме.)
Иногда одни клиенты приводят других, что показывается с помощью рекурсивной связи КЕМ_ПРИВЕДЕН. Клиент может привести одного или нескольких других клиентов. Клиент не обязан быть приведен другим клиентом, но каждого клиента может привести только один клиент.
Сущность СЕРТИФИКАЦИЯ_ИНЖЕНЕРА показывает, что данный инженер получил образование и прошел тестирование, требуемое для получения конкретного сертификата. Инженер может иметь сертификаты (сущность СЕРТИФИКАТ). Существование сущности СЕРТИФИКАЦИЯ_ИНЖЕНЕРА зависит от сущности ИНЖЕНЕР через связь ИНЖЕНЕР-КВАЛИФИКАЦИЯ. СЕРТИФИКАТ - это сущность, описывающая конкретный сертификат.
Документирование делового регламента
В главе 2 в качестве элементов схемы базы данных были введены таблицы, связи, домены и деловой регламент. Первые три элемента присутствуют в модели «сущность—связь» или логически выводятся из нее, но деловой регламент в этой модели никак не упомянут. Таким образом, правила, составляющие деловой регламент, иногда добавляются к ER-модели на стадии моделирования данных.
ER-модель разрабатывается исходя из анализа требований, сформулированных пользователями. В процессе этого анализа часто возникает вопрос о деловом регламенте, и, разумеется, системные аналитики должны взять себе за правило спрашивать о нем пользователей.
Рассмотрим сущности ГРУЗОВИК и ИНЖЕНЕР на рис. 3.11. Имеются ли в деловом регламенте правила, касающиеся того, за кем может быть закреплен грузовик? Если имеющегося количества грузовиков недостаточно для того, чтобы закрепить грузовик за каждым инженером, то какие правила будут определять то, кому достанется грузовик? Быть может, приложение базы данных должно назначать грузовики в пользование тем инженерам, в графике которых стоит наибольшее количество работ в течение определенного периода времени или наибольшее количество работ вне офиса; возможны и другие варианты.
Другой пример — распределение работ между инженерами. Могут существовать правила, определяющие то, каким набором сертификатов должен обладать
инженер, чтобы быть допущенным к выполнению определенных видов работ. К примеру, может быть, что для инспектирования многоквартирного дома инженер должен иметь лицензию профессионального инженера. Даже если закона, предписывающего такой порядок, не существует в природе, данное правило может быть продиктовано политикой компании.
Выполнение правил делового регламента может (по не обязано) обеспечиваться средствами СУБД, а может быть организовано в прикладной программе. Иногда деловой регламент формулируется в виде процедур, которым должны следовать пользователи приложения базы данных. На данный момент способ, с помощью которого организуется выполнение правил делового регламента, не имеет значения. Важно документировать эти правила, чтобы они стали частью системных требований.