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

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

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), и в дополнение к собственной связи скорняжный_пошив наследует от Изделие связи мастера и выполняется_в.

4.1.10. Множественное наследование в ODL

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

Пример 4.9. Можно определить подкласс жилет класса Изделие:

1) interface Жилет: Изделие{

2) attribute string материал_спинки;

};

Все жилеты имеют атрибут, выражающий определяющий материал спины, а также все атрибуты и две связи, которыми обладают все изделия.

Теперь рассмотрим изделие " жилет из меха", являющееся и меховым изделием, и жилетом. Кроме обычных свойств класса Изделие, такие изделия должны иметь связь скорняжный_пошив и атрибут материал_спинки. Эту ситуацию можно описать, определив подкласс, являющийся подклассом обоих классов Меховое_изделие и Жилет:

interface Меховой_жилет: Меховое_изделие, Жилет {

};

Итак, объект Меховой жилет определяется для выражения всех свойств обоих подклассов Жилет и никаких свойств или связей, принадлежащих только меховым жилетам, не вводится. Объекты класса Меховой_жилет наследуют атрибут материал_спинки класса Жилет и связь скорняжный_пошив класса Меховое_изделие. Поскольку классы Жилет и Меховое_изделие, в свою очередь, наследуют атрибуты и две связи класса Изделие, класс Меховой_жилет наследует также и эти атрибуты и свойства. Однако он не наследует двух копий всех этих свойств, а наследует свойства из класса Изделие через любой из двух его непосредственных подклассов. Рис. 46 иллюстрирует связи подкласс-суперкласс, в которых участвуют четыре названных класса.

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

Пример 4.10. Предположим, что класс Изделие имеет подклассы Кожаное_изделие и Меховое_изделие, каждый из которых имеет атрибут стиль. Но в классе Кожаное_изделие этот атрибут получает значения из набора {молодежный, всевозрастной}, а в классе Меховое_изделие – из набора {модный, традиционный}. Если затем вводится новый подкласс Кожано-меховое_изделие, суперклассами которого являются Кожаное_изделие и Меховое_изделие, тип наследуемого атрибута стиль в классе Кожано-меховое_изделие остается неясным.

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

1. Можно указать, какое из двух определений данного свойства относится к подклассу. Так, в примере 4.10 считаем, что для изделия из кожи и меха важен не показатель модности, а целевая возрастная категория. Тогда устанавливается, что класс Кожано-меховое_изделие наследует атрибут стиль из суперкласса Кожаное_изделие, а не Меховое_изделие.

2. Можно присвоить в классе С новое имя одному из двух наследуемых свойств с одним и тем же именем. Если в примере 4.10 Кожано-меховое_изделие наследует атрибут стиль из класса Кожаное_изделие, в этом классе можно определить дополнительный атрибут фасон как результат замены имени атрибута стиль, наследуемого из класса Меховое_изделие.

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

Заметим, что даже в примере 4.9 есть конфликты: Кожано-меховое_изделие наследует из каждого непосредственного суперкласса (Меховое_изделие и Кожаное_изделие) свойства, в том числе назв_изделия и мастера, которые эти классы наследовали из класса Изделие. Но поскольку определения назв_изделия и других свойств идентичны в обоих суперклассах, выбирать используемое определение можно вообще любым способом.

4.1.11. Моделирование ограничений

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

Ключи

В ODL ключ класса – это такое множество атрибутов А, что при наличии в данном классе двух различных объектов 01 и 02 они не могут иметь идентичных значений для любого атрибута в ключе К.

В ODL один или несколько атрибутов описываются как ключи класса с помощью ключевого слова key или keys (любого из них), за которым указываются атрибуты, формирующие ключ. Если в ключе больше одного атрибута, список атрибутов заключается в круглые скобки. Описание ключа должно стоять непосредственно за описанием интерфейса, перед открывающей фигурной скобкой или любыми атрибутами либо связями. Само описание ключа заключается в круглые скобки.

Пример 4.11. Чтобы показать, что множество, состоящее из атрибутов фамилия, имя, отчество является ключом для класса Мастер, строка 7 в примере 4.4 заменяется на:

interface Мастер

(key (фамилия, имя, отчество)) { };

Вместо key можно применять keys даже если описывается только один ключ.

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

Пример 4.12. Чтобы проиллюстрировать ситуацию, в которой уместно иметь более одного ключа, рассмотрим класс Сотрудник. He будем описывать здесь все множество его атрибутов и связей, но предположим, что его атрибутами являются empID – идентификатор сотрудника и ssNo – номер страхового полиса. Тогда эти атрибуты можно описать как ключ:

(key empID, ssNo).

Поскольку список атрибутов здесь не заключен в скобки, в ODL это означает, что каждый из атрибутов сам является ключом. Если заключить в скобки пару (empID, ssNo), в ODL считается, что эти два атрибута вместе формируют один ключ. Из записи

(key (empID, ssNo))

следует именно то, что никакие два сотрудника не могут иметь один и тот же ID и один и тот же номер страхового полиса, хотя два сотрудника могут совпадать по одному из этих атрибутов.