4.1.8. Проектирование с использованием odl

В данном разделе рассматриваются некоторые полезные принципы проектирования с использованием объектно-ориенти-рованного подхода.

Правильность

Самое важное: проект должен быть адекватным конкретной предметной области, правильно отображать реальный мир. Классы или множества сущностей и их атрибуты, должны отражать реальные объекты. Нельзя приписывать мастеру-портному атрибут "число цилиндров", хотя это имеет смысл для класса автомобилей. Любые установленные связи должны соотноситься с нашими знаниями о моделируемой части реального мира.

Пример 4.7. Если определяется связь мастер_для между Мастер и Изделие, она должна быть типа "многие-ко-многим", так как наблюдения за реальным миром показывают, что мастера могут быть заняты работой над многими изделиями, и изделия могут (не обязательно, но могут) выполняться несколькими мастерами. Неверно определять эту связь как " связь типа "один-к-одному".

Устранение избыточности

Необходимо следить за тем, чтобы каждый факт упоминался не более одного раза. Например, мы использовали связь обеспечивает между изделиями и цехами. Можно было бы еще ввести атрибут название_цеха или множество сущностей Изделия, в чем нет ничего незаконного. Однако это опасно по многим причинам.

1. Необосновано увеличивается необходимый объем памяти, одно описание факта займет всегда меньше места, чем два описания.

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

С первого взгляда может показаться, что использование связи и ее обращения в ODL – это пример излишеств в модели. Однако не следует полагать, что связь и ее обращение будут представлены двумя различными структурами данных, например указателями в различных направлениях. Вспомните, что определение связи и ее обращения лишь отражают тот факт, что связи в принципе можно придать любое направление.

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

И еще один важный момент. Не стоит вводить в проект больше элементов, чем это необходимо.

4.1.9. Подклассы

Наследование является одним из основополагающих принципов ООП. Довольно часто класс содержит объекты с особыми свойствами, не связанными со всеми членами этого класса. В данном случае рекомендуется разделить класс на подклассы, каждый из которых будет иметь собственные специальные атрибуты и/или связи в дополнение к тем, что присущи классу как единому целому. Сначала рассмотрим простой способ описания подклассов в ODL, а затем (в следующей главе) покажем, как иерархии класс-подкласс представляются в E/R-модели с помощью специальных связей под названием "isa" ("А есть В" выражает связь "isa" подкласса А с подклассом В).

В рассматриваемом в качестве примера БД ателье могут заказываться платья, костюмы, шубы и множество других типов изделий. Для каждого из этих типов можно определить подкласс класса Изделие, введенного в примере 4.1. По определению класс С является подклассом другого класса D если в описании за именем С следуют двоеточие и имя класса D.

Пример 4.8. Для иллюстрации будем различать труд портного и скорняка. Меховое_изделие – это подкласс класса Изделие, следовательно, Изделие – это суперкласс класса Меховое_изделие. Выразим это простым ODL-описанием:

1) interface Меховое_изделие: Изделие {

2) relationship Set<Мастер> скорняжный_пошив;

};

Строка (1) показывает, что Меховое_изделие – подкласс класса Изделие. Строка (2) означает, что все объекты класса Меховое_изделие имеют связь скорняжный_пошив с мастерами, выполняющими скорняжную работу. В описании не указано имя обращения этой связи, хотя технически это следовало бы сделать. Заметим, что связь скорняжный_пошив имеет смысл не для всех изделий, а только для меховых изделий, поэтому не вводится для класса Изделие.

Подкласс наследует все свойства своего суперкласса (называемого также классом, из которого выводится подкласс). Другими словами, любые атрибут и связь суперкласса автоматически являются атрибутом и связью его подкласса. В примере 4.8 каждый объект класса имеет все атрибуты, наследованные от Изделие (вспомните пример 4.4), и в дополнение к собственной связи скорняжный_пошив наследует от Изделие связи мастера и выполняется_в.