Базы данных

Заказы на покупку и содержание видеокассет


Класс PurchaseOrder можно определить как слабый класс. Кардинальности его связей требуют, чтобы заказ на покупку имел одного поставщика и по меньшей мере одну видеокассету; следовательно, заказ на покупку не может существовать без связей с другими сущностями. Такая структура является одной из характеристик слабого класса. Его естественным ключом является некая комбинация даты, кода поставщика и заказываемых кассет. В этом случае гораздо удобнее создать искусственный ключ (id) и определить PurchaseOrder как сильную сущность, что и сделано на 2.8.

Слабая сущность не имеет собственного ключа. Примером такого класса для BigHit Video является класс PayStatement. Этот класс не имеет ключа потому, что многие сотрудники могут получать зарплату в один день. Тип связи PaidTo (выплачено), однако, является связью “многие к одному”, связывающей каждую запись о выплате с одним служащим.

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

Эта стратегия не является общепринятым подходом для представления процесса закупки. Обычно заказ на покупку содержит список приобретаемых изделий. Каждое изделие имеет некоторую идентифицирующую ее информацию (например, номер по каталогу) и количество. Например, это может быть намерение приобрести 25 копий фильма Lady and Tramp. Диаграмма на 2.8 потребует в этом случае, чтобы были созданы 25 сущностей, все с одинаковым названием “Lady and Tramp”, жанром “анимационная комедия” и с уникальными значениями атрибута videold. Далее, каждая сущность должна быть индивидуально связана с заказом на покупку. Результатом будет размещение заказа из 25 пунктов вместо одного пункта с количеством 25.

Этот подход является очевидной ошибкой диаграммы. Чтобы концептуальная схема была корректной, она должна в точности соответствовать представляемым ею реальным объектам. Как оказалось, сущность PurchaseOrder не может служить точным представлением реального заказа на покупку.

Может возникнуть искушение снабдить тип связи Orders атрибутом количества, как показано на 2.9. В таком случае заказ на покупку представляет собой множество пунктов, для каждого из которых указано количество. Однако в такой модели изменяется смысл сущности VideoTape. В диаграмме на 2.8 сущность VideoTape представляет совершенно определенную кассету с видеофильмом, которую можно взять напрокат. На 2.9 сущность VideoTape представляет определенное название фильма, а не определенную кассету с этим фильмом. Видеофильм теперь может быть куплен несколько раз и может представлять более чем одну физически существующую кассету.

Комментарии закрыты