Сущности. Лучше всего начать построение модели «сущность—связь» с определения потен­циальных

Лучше всего начать построение модели «сущность—связь» с определения потен­циальных сущностей. В документах или беседах сущности обычно представляют­ся существительными (места, люди, концепции, события, оборудование и т. п.). Исследовав предыдущий пример на предмет важных словосочетаний, относящих­ся к информационной системе, мы получим следующий список:

- индивидуальное занятие;

- групповое занятие;

- инструктор;

- постоянный инструктор;

- приходящий инструктор;

- вечер танцев;

- клиент.

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

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

Чтобы сделать правильный выбор среди этих альтернатив, необходимо про­анализировать требования и выяснить, каким образом данные требования отра­зятся на структуре системы. Иногда полезно рассмотреть атрибуты сущностей. Если, например, сущность ЗАНЯТИЕ не имеет никаких атрибутов, кроме иденти­фикатора, то вводить такую сущность нет необходимости.

Связи

Начнем с того, что сущность ИНСТРУКТОР имеет два подтипа: ПОСТОЯННЫЙ_ИНС-ТРУКТОР и ПРИХОДЯЩИЙ_ИНСТРУКТОР. Любой инструктор должен быть либо по­стоянным, либо приходящим, значит, подтипы являются взаимоисключающими.

Далее рассмотрим связи между сущностями ИНСТРУКТОР и ИНДИВИДУАЛЬНОЕ_ ЗАНЯТИЕ или ГРУППОВОЕ_ЗАНЯТИЕ. Инструктор может проводить много индиви­дуальных занятий и, как правило, индивидуальное занятие проводится одним инструктором. Но в ходе дальнейшего разговора с менеджерами танцевально­го клуба выясняется, что для продвинутых танцоров, особенно тех, кто гото­вится к соревнованиям, к индивидуальным занятиям иногда привлекается два инструктора. Поэтому связь между сущностями ИНСТРУКТОР и ИНДИВИДУАЛЬНОЕ_ ЗАНЯТИЕ должна иметь тип «один ко многим». По поводу групповых занятий мы, однако, будем полагать, что каждое из них ведет только один инструктор. Связи, описанные нами только что, изображены на рис. 3.17.

Клиенты могут посещать как индивидуальные, так и групповые занятия. Ино­гда индивидуальное занятие проводится с одним человеком, а иногда — с парой. Есть два способа моделирования этой ситуации. Можно определить сущность ПАРА как имеющую связь 1:2 с сущностью КЛИЕНТ, а можно допустить, что обе сущности, КЛИЕНТ и ПАРА, могут иметь связь с сущностью ИНДИВИДУАЛЬНОЕ_ ЗАНЯТИЕ. Мы предполагаем, что пары не посещают групповые занятия, а если и посещают, то этот факт не настолько важен, чтобы записывать его в базу данных. Эта альтернатива показана на рис. 3.18, а.

Существование сущности ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ зависит от сущностей КЛИЕНТ и ПАРА. То есть занятие не может существовать, если оно не проводится с каким-либо клиентом или парой. Число 1 рядом с горизонтальной линией, проведенной на рисунке под сущностями КЛИЕНТ и ПАРА, показывает, что в инди­видуальном занятии должны участвовать как минимум один клиент или одна пара, что разумно, поскольку индивидуальное занятие зависит от них.

Альтернатива заключается в том, чтобы не вводить пары, а указать тип связи между сущностями КЛИЕНТ и ИНДИВИДУАЛЬНОЕ_ЗАНЯТИЕ как «многие ко многим». Если быть более точным, эта связь должна иметь тип «один или два ко многим», как показано на рис. 3.18, б. Хотя эта модель является не такой подробной, как модель на рис. 3.18, а, ее может быть вполне достаточно для нужд танцевального клуба Джефферсона.

Осталось рассмотреть возможные связи сущности ВЕЧЕР_ТАНЦЕВ с другими сущностями. Вечера танцев посещают как инструкторы, так и клиенты, и разработчики должны решить, важно ли показывать эти связи в структуре базы данных. Действительно ли для танцевального клуба важно знать, какие клиенты посетили какие танцевальные вечера? Так ли уж хотят менеджеры клуба вести запись посе­тителей в компьютерную информационную систему при входе в танцзал? И захо­чется ли посетителям, чтобы эти данные записывались? Скорее всего, эти связи не принадлежат к числу тех, которые требуется или следует хранить в базе данных.

Иначе обстоит дело со связью между сущностями ВЕЧЕР_ТАНЦЕВ и ИНСТРУКТОР. Хозяин клуба любит, когда на танцевальных вечерах присутствуют несколько клубных инструкторов. В связи с этим требованием правление клуба состави­ло расписание посещения вечеров инструкторами. Составление и запись этого расписания требуют, чтобы в базе данных присутствовала связь ВЕЧЕР_ТАНЦЕВ-ИНСТРУКТОР, которая имеет тип «многие ко многим».

Дата добавления: 2015-07-08