5everage итки). совершенно не применим к категории Dairy-Products (Молочные продукты) - и категория отдельного продукта изменяется. Что делать в подобной ситуации? Удалять все старые значения? А если изменение было сделано по ошибке, и пользователь хочет немедленно его отменить?

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

ставших неприменимыми, возможность удалять данные,

когда вы действительно хотите это сделать, На рис. 3-11 показана модель, в которой используется реализация сущностей как классов-наследников.

Orders

Т OrderDetailii -Ф-

Products

Confections

Grains/ Cereals

Produce

Гис. 3-11. Модель, в которой используется ованае классов, сочетает в себе все преимущества моделей, показанн1х на рис. 3-9 и 3-10

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

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

Часто дл jcHni!, между которыми существуют связи один к одному , нелегко правильно определить ссылающееся и ссылочное отношения, исходя из семантики модели данных. Если вы воспользоваться методом реализации сущностей как классов-наследников, то производящая сущность (generic entity) будет ссылочным отношением, а каждый из ее классов-наследников - ссылающимся.

ПРИМЕЧАНИЕ В таких случаях внешний ключ вуюший для классов-наследников, часто является индидатом. поскольку не имеет смысла определять для классов-наследников собственные идентификаторы.

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

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

Связи один ко многим

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

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

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

Client

-о} CustomerServiceRep

Гис. 3-12, Эта связь является необязательной в обоих направлениях

Связь между сущностям/;? / и CustomerServiceRep является необязательной в обоих направлениях. Это означает, что у Customer-ServiceRep может быть произвольное число клиентов, в том числе и ни одного. Атрибут клиента CustomerServiceRep, если таковой определен, должен присутствовать в отношении CustomerServiceRep. Определение необязательного участника один ко многим важно, как для так и для эксплуатации системы. Подробнее об этом

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

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

ное, и его ключ-кандидат копируется в отношение, в

связи со стороны многие , которое является щимся, Ключ-кандидат ссылочного отношения часто выступает как составная часть отношения, участвующего в связи со стороны однако не

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

отношения. Чтобы сформировать ключ-кандидат ссылающегося отношения, ключ ссылочного отношения следует скомбинировать с одним или несколькими другими атрибутами.

Связ огие ко многим

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

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