Теория и практика построения баз данных (1088289), страница 20
Текст из файла (страница 20)
Иерархии генералпзацнн имеют специальнуго характеристику, называемую наследоеаггием (ш!~егйапсе), которая означает, что подтппы классов сущностей наследуют атрибуты от надтипа. Сущность ТОВАРИЩЕСТВО, к примеру, наследует атрибуты ИмяКлиента и СуммаКОллате от сущности КЛИЕНТ. Причины, по которым подтнпы используются в моделировании данных, отличаготся от причин, по которым они используются в объектно-ориентированном программировании. Фактически, в модели данных они применяются с единственной целью: избежать ситуаций, прн которых некоторые атрибуты должны иметь пулевые значения. Например, на рпс.
3.10, а, если атрибуту НомерСоциальнойСтраховки присвоено значение, то остальные четыре атрибута должны быть равны нулю. Эта ситуация наиболее ярко проявляется в медицинских приложениях; представые себе, например, что пациенту мужского пола задается вопрос о количестве беременностей.
Нулевые значения более детально обсуждаются в главе 6. На рис. 3.11 показан пример ЕН-дггаграьгьгы, содержащей все элементы модели «сущность — связь», о которых шла речь до сих пор. Она изображает сущности и связи для инженерной консалтинговой кохгпаггггьг, которая занимается анали- зом строительства и состояния домов и других зданий н сооружений.
КЕМ ПРИВЕДЕН Рис. 3.11. Пример диаграммы «сущность — связь» На диаграмме есть класс сущностей, представляющий сотрудников компании. Поскольку некоторые сотрудники являются инженерами, сущность СОТРУДНИК Элементы модели «сущность — связь» 95 связана с сугггностью ИНЖЕНЕР как подтип. Каждый инженер должен быть сотрудником; сущность ИНЖЕНЕР имеет связь 1;1 с сущностью ГРУЗОВИК; каждый грузовик должен быть закреплен за каким-то инженером, но не у всех инженеров есть грузовики. Инженеры выполняют работы (супгность РАБОТА) для клиентов (сушность КЛИЕНТ). Инженер может не выполнять никаких работ (иначе говоря, выполнять ноль работ) пли выполнять много работ, но каждая отдельно взятая работа может выполняться только одним конкретным инженером.
Для одного и того же клиента может выполняться много различных работ, и один и тот же вид работы может выполняться для множества клиентов. Клиент должен оплатить как минимум одну работу, но различные виды работ сугцествуют независимо от клиентов. Связь КЛИЕНТ-РАБОТА имеет атрибут Плата, который показывает сумму, уплаченную конкретным клиентом за конкретную работу. (Прочие атрибуты сущностей и связей не показаны на этой диаграмме.) Иногда одни клиенты приводят других, что показывается с помощью рекурсивной связи КЕМ ПРИВЕДЕН.
Клиент может привести одного или нескольких других клиентов. Клиент не обязан быть приведен другим клиентом, но каждого клиента может привести только один клиент. Сущность СЕРТИФИКАЦИЯ ИНЖЕНЕРА показывает, что данный инженер получил образование и прошел тестирование, требуемое для получения конкретного сертификата. Инженер может иметь сертификаты (сушность СЕРТИФИКАТ). Существование сущности СЕРТИФИКАЦИЯ ИНЖЕНЕРА зависит от сущности ИНЖЕНЕР через связь ИНЖЕНЕР-КВАЛИФИКАЦИЯ, СЕРТИФИКАТ вЂ” это сущность, описывающая конкретный сертификат. Документирование делового регламента В главе 2 в качестве элементов схемы базы данных были введены таблицы, связи, домены и деловой регламент. Первые три элемента присутствуют в модели «сущность — связь» пли логически выводятся из нее, но деловой регламен~ в этой модели никак не упомянут.
Таким образом, правила, составляющие деловой регламент, иногда добавляются к ЕК-модели на стадии моделирования данных. ЕК-модель разрабатывается исходя из анализа требований, сформулированных пользователями. В процессе этого анализа часто возникает вопрос о деловом регламенте, и, разумеется, системные аналитики должны взять себе за правило спрашивать о нем пользователей. Рассмотрим сущности ГРУЗОВИК и ИНЖЕНЕР на рис 3.11.
Имеются ли в деловом регламенте правила, касаюпцгеся того, за кем может быть закреплен грузовик? Если имеющегося количества грузовиков недостаточно для того, чтобы закрепить грузовик за каждым инженером, то какие правила будут определять то, кому достанется грузовик? Быть может, приложение базы данных должно назначать грузовики в пользование тем инженерам, в графике которых стоит наибольшее количество работ в течение определенного периода времени или наибольшее количество работ вне офиса; возможны и другие варианты.
Дру~ой пример — распределение работ между инженерами. Могут существовать правила, определяющие то, каким набором сертификатов должен обладать ° т СОТРУДНИК АВТОМОБИЛЬ СПУЖЕБНЫЙ АВТОМОБИЛЬ 0,.1 1..1 НомерСструдника Имя Должность Телефон КодКвалификации Номерпицензки ШННомер Производитель Модель ГодВыпуска г Ограничения и методы перечисляются здесь Ограничения н методы перечисляются здесь г СТУДЕНТ КЛУБ СТУДЕНТ-КЛУБ НомерСтудента ИмяСтудента Телефон Группа Комната Намерклуба КодИсточникаоинансиравания Описание Президент ТепефонПрезидента Ограничения и методы перечисляются здесь Ограничения и методы перечисляются здесь 96 Глава 3.
Модель сущность — связь» инженер, чтобы быть допущенным к выполнению определенных видов работ. К примеру, может быть, что для инспектирования многоквартирного лома инженер должен иметь лицензию профессионального инженера. Даже если закона, предписывающего такой порядок, не существует в природе, данное правило может быть продиктовано политикой компании. Выполнение правил делового регламента может (но не обязано) обеспечиваться средствами СУБД, а может быть организовано в прикладной программе.
Иногда деловой регламент формулируется в ниде процедур, которым должны следовать пользователи приложения базы данных. На данный момент способ, с помощью которого организуется выполнение правил делового регламента, не имеет значения. Важно документировать эти правила, чтобы они стали частью системных требований. Модель «сущность — связь» и САЗЕ-средства Разработка моделей данных в рамках модели «сущность — связьь значительно упростилась в последние годы, поскольку теперь инструменты для построения ЕК-диаграмм входят в состав многих популярных САЯЕ-средств. К таким продуктам относятся, в частности, 1ЕТУ, 1ЕЕ, 1)ЕгТ, Ерк-%1Х и ьг!з!о.
Эти продукты также объединяют сущности с отношениями, с помощью которых эти сущности представлены в базе данных, что может облегчить администрирование, управление и обслуживание базы данных. Мы не предполагаем работать с САЯЕ-средствами в рамках данной книги. Но если в вашем университете имеется такое средство, всеми способами используйте его для создания Е11-диаграмм при выполнении назначенных вам упражнений. Егк-диаграммы, созданные с помогцью САБЕ-средств, обычно имеют более красивый вид, и их гораздо легче изменять и адаптировать. Диаграммы 11сущность — связь» в стиле 0М$ Унифицированный язык моделирования (Н МЕ) — это набор структур и методик для моделирования и проектирования объектно-ориентированных программ (ООП) и приложений.
ПМŠ— это одновременно и методология разработтси систем ООП, и набор инструментов для разработки таких систем. ОМ1. получил известность стараниями группы ОМС (О!т)ест Мапайешепг Огоир) — организации, которая занимается разработкой ООП-моделей, технологии и стандартов с 1980-х годов. Этот язык стал также находить широкое применение в среде профессионалов ООП. На НМЕ базируются инструменты для объектно-ориентированного проектирования, разработанные компанией Кат!она! Яузтетз. Будучи методологией разработки приложений, ПМЕ является предметом курса системной разработки и поэтому представляет для нас лишь ограниченный интерес. Вам могут, однако, встрсппься диаграммы «сущность — связь», выполненные в стиле 1)МЕ, поэтому представление об этом стиле следует иметь.
Диаграммы «сущность — связь» в стиле ОМ1. 97 Нужно просто осознать, что когда дело касается проектирования баз данных, об- ращение с этими диаграммами происходит точно так же, как и с традиционными Ей-диаграммами. Сущности и связи в 0М~. На рис. 3.12 приведено ПМЕ-представление структур, изображенных на рис. З.З. Каждая сущность представлена классом сущностей, который изображен в виде прямоугольника с тремя сегментаьпь В верхнем сегменте указано имя сущности н другие данные, о которых мы будем говорить далее. Во втором сегменте перечислены имена атрибутов сущности, а в третьем описаны ограничения и методы (программные процедуры), относящиеся к данной сущности. е Рис.
3.12. Представления различных типов связей в Омгц а — связь 1:1; о — связь 1:Н; а — связь Н:М КЛИЕНТ НомерКпиента ИмяКпивнта СуммаКОплате Идентификатор: НомврКлиента Методы ТипКлиента ФИЗИЧЕСКОЕ ЛИЦО КОРПОРАЦИЯ Адрес НомерСоцкальнойСграховки ДоверенноеЛицо Телефон ИдентификационныйНалоговыйНомер Методы Методы ТОВАРИЩЕСТВО ИмяуправляющвгоПартнвра Адрес ИдентификационныйНалоговыйНомер ПРОЕКТ Методы НазваниеПроекта ДатаНачала Датазавершения КодИсточникаФинансирования Рис. 3.14.
Представление подтипов в ОМС ИмяСотрудника Ограничения и методы перечисляются здесь Идентификатор: НазваниеПровкта Методы 98 Глава 3. Модель «сущность — связь» Связи показаны линиями, соединяющими две сущности. Кардинальность представлена в формате х..у, где х — это необходимый минимум, а у — допустимый максимум, Так, 0.,1 означает, что наличие данной сущности необязательно, а максимально допустимое количество — одна. Звездочка представляет неограниченное количество. Например, запись 1.." означает, что требуется одна сущность, а допускается неограниченное количество.
Найдите на рис. 3.12, а, 6 примеры связей с максимальной кардинальностью 1:1, 1:Х и Х:М. Представление слабых сущностей На рис. 3.13 изображено () МЕ-представление слабых сущностей. На линии связи рядом с родителем слабой сущности (то есть рядом с сущностью, от которой зависит слабая сущность) помещается закрашенный ромб, На рис.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
