Глава 8: Обобщения и специализации.

В первых нескольких главах этой книги, мы представляли ER-диаграмму, как инструмент для разработки концепции базы данных. Мы использовали такой подход при разработкеER-диаграмм, при котором нам необходимо разработать для пользователя модель реальной ситуации. И хотя мы работали с базовымиER-диаграммами, существуют ситуации, для которых нельзя достаточно полно описать все хранимые данные с помощью базовой модели. С расширением области применения баз данных, базовых понятийER-моделирования (которые были предложены Ченом) оказывается уже недостаточно для выполнения требований более сложных приложений, таких как специализация и обобщение.

ERмодель, которая описывает такие дополнительные семантические понятия, называетсяEnhancedEntityRelationship–EER. (ElmasriandNavathe, 2000). Эта глава обсуждает обобщения и специализацииEER-модели и разрабатывает методологию и грамматику для данных понятий.

Что такое обобщение и специализация?

EERмодель включает все понятия оригинальнойERмодели и дополнительные понятия обобщений и специализаций. Обобщения и специализации связаны с понятием надклассов и подклассов и наследуемыми атрибутами.

Понятие класс включает использование простых атрибутов, которые мы видели. В программировании, класс также включает действия, которые он может выполнять. Работая с типами данных, базы данных стремятся больше использовать атрибуты, чем процедурные действия. Идея классов также обращается к способности описать надкласс и подкласс с наследуемыми характеристиками. Например, сущность СТУДЕНТ включает информацию о студентах. Предположим теперь, что нам необходимо хранить информацию обо всех людях в институте – не только о студентах, но также о служебном персонале и преподавательском составе. Мы можем думать о надклассе СУБЪЕКТ, который включает в себя подкласс СТУДЕНТ, другой подкласс – СЛУЖАЩИЙ и ещё один подкласс – ПРЕПОДАВАТЕЛЬ. Очевидно, информация о каждом из подклассов заключается в надклассе СУБЪЕКТ. Помимо этого, надкласс СУБЪЕКТ должен включать информацию, принадлежащую всем из подклассов. Сущность СУБЪЕКТ может содержать имя, адрес, телефон; и когда определён класс СЛУЖАЩИЙ, он может унаследовать эти атрибуты из надкласса и определить другие атрибуты, относящиеся только к подклассу СЛУЖАЩИЙ. Надкласс в базах данных называется обобщением, а подкласс (студент, служащие, факультет) называется специализацией.

Проблема с вариантами

Чтобы наглядно представить проблему с ER-диаграммами, представим себе ситуацию, что вы собираете информацию для разработки баз данных и достигли такого момента, когда один из атрибутов сущности может изменять свое значение в зависимости от ситуации. К примеру, предположим, что мы моделируем БД о студентах-спортсменах, которые занимаются более чем одним видом спорта. Мы, конечно, запишем информацию о студенте – имя, номер студента в качестве уникального идентификатора, возможно, некоторую другую информацию. Но после этого, нам бы хотелось записать информацию о видах спорта, которыми занимается студент. Предположим, что у нас естьтаблицастудентов-спортсменов со следующими данными:

Некоторая информация сущности СПОРТСМЕН содержит атрибуты, которые могут иметь различные значения для различных видов спорта. Эти различные значения называются «вариантами». Проблема вариантов при обработке данных решалась различными способами на протяжении многих лет. Решением проблемы вариантов в записях БД и переменных атрибутах в сущностях является исключение вариантов и ссылка на них через первичный ключ родительской сущности.

В ERдиаграммах, мы представляем, что храним информацию о двух различных, но связанных, объектах: (1) обобщении – «студенте», который имеет имя, номер и т.д.; и (2) специализации – спорте (теннис, футбол, гольф и т.д.). Каждый объект обладает некоторым набором атрибутов. И поскольку мы храним информацию о двух объектах, почему бы не создать сущность СТУДЕНТ и не связать ее с сущностью СПОРТ? Одна сущность СПОРТ не будет работать, потому что сущность СПОРТ должна быть общей и нам бы хотелось хранить информацию о различных видах спорта. К тому же, мы хотим что бы хранилась информация о видах спорта, которыми занимается каждый студент в отдельности.

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

Пример обобщений и специализаций

Обобщения и специализации являются категориями сущностей, при этом сущности специализаций могут быть результатом обобщений, содержащих варианты. Эти варианты проще всего контролировать, исключая вариант из обобщения и рассматривая его как подкласс, и оставляя начальную, “неизменяемую часть” сущности как надкласс или родительский тип. Если бы мы ссылались на надкласс как на родительский класс, мы бы назвали изменяемые части, или надклассы, дочерними классами.

Рассматривая идею родительского-дочернего надкласса/подкласса несколько шире, мы можем представить, что дочерний класс наследует свойства родительского. Наследование в данном контексте означает, что дочерний класс определён в независимости от того определены ли атрибуты в родительском классе. В нашем примере про спортмы может определить класс СТУДЕНТ как родительский, а СПОРТ как дочерний класс, поэтому когда мы определим информацию о виде спорта, она будет добавлена в контекст родительского класса - СТУДЕНТ.

Если бы мы разрабатывали базу данных СТУДЕНТ–СПОРТСМЕН, мы бы определили, что необходимо записывать имя, уникальный идентификатор (номер), адрес и т.п., то есть мы бы начали с некоторого обобщения (родительского класса, или надкласса). Затем мы бы решили записать спортсмена и некоторую информацию о виде спорта. Говорится, что спортсмен, является специализацией класса студент. Такой подход можно назвать «сверху вниз».

Если бы мы стали разрабатывать базу данных с класса СПОРТ, то мы могли бы иметь сущности ТЕННИС, ФУТБОЛ и т.д. для каждого спортсмена, а затем обнаружили бы, что эти сущности можно обобщить в сущности СУБЪЕКТ (надкласс) с индивидуальными видами спорта (сущностями-подклассами). Такой метод можно назвать «снизу вверх». Связь обобщения означает, что несколько типов сущностей с некоторыми общими атрибутами могут быть обобщены сущностью более высокого порядка, то есть родительским классом, или надклассом.

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

В качестве иллюстрации понятий обобщения и специализации рассмотрим следующий пример. Предположим, что определена сущность СПОРТСМЕН:

Сущность: СПОРТСМЕН

Атрибуты: имя, уникальный номер, адрес, пол, вес, рост.

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

Рисунок 8.1. Студент-Спортсмен с попыткой добавить переменные атрибуты.

Что не так на рисунке 8.1? Проблема в том, что у нас есть атрибуты, которые имеют атрибуты. «Признак вида спорта» не является составным атрибутом, следовательно, он не должен иметь составных частей.Вместо того, чтобы создавать атрибуты с атрибутами, мы создадим самостоятельную сущность для каждого определенного вида спорта, и затем свяжем эти сущности со СПОРТСМЕНОМ.

Теперь обратимся к рисунку 8.2. На нём созданы слабые сущности для каждого вида спорта. В самом деле, если бы виды спорта были реальными сущностями, их стоило бы определить как слабые, поскольку они зависят от СПОРТСМЕНА для своего существования, то есть они не имеют первичного ключа. Но мы не будем изображать сущности видов спорта слабыми, а будем использовать другую модель, которая подразумевает наследование.

Рисунок 8.2. Связь Студент-Спортсмен изображена как сильная/слабая связь с переменными

атрибутами.

Процесс специализации подразумевает наследование подклассом всех свойств родительского класса. Сущность спортсмен не имела бы смысла, если бы была одна, и поэтому необходима связь с определяющим ее надклассом. В EERтерминологии, сущность СПОРТСМЕН называется надклассом, а сущность ВИД СПОРТА – подклассом. Такой атрибут, как гандикап может быть назван «специфическим атрибутом», так как он свойственен отдельному подклассу. Другими словами, каждый член подкласса также является членом надкласса. Член подкласса является таким же, как и сущность в надклассе, но имеет отличную роль.

Сущности видов спорта, или специализации, изображаются на EERсхеме как показано нарисунке 8.3. На нём изображены 3 самостоятельные сущности видов спорта – то есть части той информации, которую мы хотим хранить в базе данных.

Рисунок 8.3. Связь Студент-Спортсмен изображена как сильная/слабая связь с переменными

атрибутами.

Сначала, в сущность СПОРТСМЕН мы включим атрибут вид спорта. Вид спорта называется «определяющим предикатом», так как он определяет нашу специализацию. Согласно рисунку 8.3А, определяющий предикат изображается на линии, соединяющей с сущностью СПОРТСМЕН в кружке с буквой «о». Кружок с буквой «о» внутриобозначает «ограничение пересечения». Это означает, сущности-подклассы, который соединены с кружком, могут частично пересекаться; то есть сущность надкласса быть членом более чем одного подкласса (специализации). Другими словами, пересечение (“о”) нарисунке 8.3Аозначает, что спортсмен может заниматься более одним видом спорта, например: теннис и гольф; или гольф и футбол; или гольф, теннис и футбол.

Рисунок 8.3А. Связь Студент-Спортсмен изображена как связь надкласс/подкласс.

Если на рисунке 8.3Ав кружке была бы буква «d» (вместо «o»), то сущности были бынепересекающимися. «d» указывает на то, что спортсмены могли бы заниматься только одним видом спорта, например играть только в гольф, или только в теннис, или только в футбол (но никак в два вида сразу). В другом примере, если бы в качестве определяющего предиката был выбран не вид спорта, а «штат, в котором родился», то сущности «штат, в котором родился» были бы непересекающимися, поскольку один субъект был бы представлен только в одной сущности-специализации. Такое ограничение непересечения изображено нарисунке 8.4.

Рисунок 8.4. База данных офиса с сущностями-специализациями, полным участием и

ограничением непересечения.

Согласно рисунку 8.4, вся мебель, учитываемая в базе данных – это стул, парта и стол. Отметим полное участие сущности МЕБЕЛЬ в связи с кружком «d» и сравним его с частичным участием в примере СТУДЕНТ-СПОРТСМЕН. Ограничение непересечения указывает на то, что если подклассы специализации не пересекаются, то сущность может быть членом только одного подкласса специализации.

Рисунок 8.3Aпоказывает символ подкласса ($) между предикатом, определяющим сущности, и кружком ограничений пересечения/непересечения – «Теннис», «Гольф», «Футбол» принадлежат определяющему их предикату «Вид спорта». Сущности ТЕННИС, ГОЛЬФ и ФУТБОЛ являются подклассами класса СПОРТСМЕН. Символ подкласса, изображенный на каждой линии, соединяющей подкласс с кружком, указывает направление наследования. Нарисунке 8.3подклассы ТЕННИС, или ГОЛЬФ, или ФУТБОЛ (специализации), наследуются из родительского отношения СПОРТСМЕН.

Контрольные вопросы 8.1

1. Что такое специализация? Приведите ещё один пример специализации.

2. Что такое обобщение? Приведите ещё один пример обобщения.

3. Что такое ограничение непересечения? Каким символом обозначается такое ограничение на EERдиаграмме?

4. Что такое ограничение пересечения? Каким символом обозначается такое ограничение на EERдиаграмме?

5. Что означает символ подкласса?

6. Почему предпочтительнее создавать связь обобщения/специализации, чем создавать слабые сущности?

7. Как действует наследование в связи подкласс /надкласс? Объясните.

Методология и грамматика для связей

обобщение/специализация

Нам следует пересмотреть 6 шаг методологии ER-проектирования чтобы учесть возможные связи обобщение/специализация. Предыдущая версия 6 шага была такова:

Шаг 6: Определить на структурированном английском языке точный характер связей с обеих сторон. Например, связь A:B::1:M означает связь A с B вида один-ко-многим с одной стороны и связь B с A вида многие-к-одному с другой стороны.

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

Мы внесём следующее предложение в шаг 6:

Для связей вида обобщение/специализация определить их на структурированном английском, упомянув все сущности, участвующие в связи (подклассы и специализации). Указать существующие структурные ограничения.

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

Грамматика для слабых сущностей была такова:

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

В нашем случае со спортсменами, первая попытка описать подкласс, идентифицируемый надклассом, будет выглядеть так:

Предполагаем, что для каждого СПОРТСМЕНА в ВИДЕ СПОРТА не существует уникального атрибута, достаточного для идентификации самостоятельных сущностей ВИДЫ СПОРТА. Поскольку ВИД СПОРТА не имеет потенциальных ключей, каждый ВИД СПОРТА будет идентифицироваться ключом, принадлежащим СПОРТСМЕНУ.

Более полное грамматическое описание EER- диаграммы будет выглядеть так:

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

Для рисунка 8.3Аданное описание преобразуется к виду:

Предполагаем, что для каждого вида спорта не существует уникального атрибута, достаточного для его идентификации. Поскольку вид спорта не имеет потенциальных ключей, то он будет идентифицироваться ключом (ключами), унаследованным от СПОРТСМЕНА. Специализации перекрываются). Каждый спортсмен может играть в несколько видов спорта. Отдельный вид спорта идентифицируется определяющим предикатом, видом спорта, который будет содержаться в СПОРТСМЕНЕ. Мы запишем следующие виды спорта: гольф, теннис и футбол.

Правила преобразования для обобщений и специализаций

В данном разделе мы определяем правила преобразования обобщений и специализаций в реляционную базу данных.

M7 — Для каждой сущности в связи обобщение/специализация создать одна таблицу для сущности-обобщения (если это еще не сделано в предыдущих шагах) и по одной таблице для каждой сущности-специализации. Добавить атрибуты для каждой сущности в соответствующие таблицы. Добавляется ключ сущности-обобщения в сущность-специализацию. Первичным ключом специализации будет являться первичный ключ обобщения.

Обратимся к рисунку 8.3А. Связь обобщение/специализация между СПОРТСМЕНОМ и ТЕННИСОМ, ГОЛЬФОМ и ФУТБОЛОМ будет преобразована в следующие таблицы:

Ключ сущности-обобщения (уникальный страховой номер) добавляется к сущностям- специализациям ТЕННИС, ГОЛЬФ, ФУТБОЛ и становится для них первичным ключом.

Таким образом, наша методология ER-проектирования (с учетом одного компонентаEERмодели – связи обобщение/специализация) теперь окончательно определена.

Методология ER-проектирования

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

выделить ключ и привести пример данных.

Шаг 2: Для описания базы данных использовать структурный английский язык для сущностей, атрибутов и ключей.

Шаг 3: Исследовать атрибуты в первичной сущности (возможно с помощью пользователя), чтобы выявить нужно ли записывать информацию о каких-либо атрибутах.

Шаг 3a: Если необходима информация об атрибуте, сделать атрибут сущностью и затем

Шаг 3b: Определите ее связь с родительской сущностью.

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

Шаг 4: Если можно выделить еще одну сущность, изобразить диаграмму для этой сущности и ее атрибутов. Повторить шаг 2 чтобы выяснить, возможно ли дальнейшее выделение сущностей.

Шаг 4a: Если дополнительная сущность или сущности не имеют потенциальных ключей, то изобразить их как слабые сущности (как описано на шаге 3c) и указать связь с идентифицирующей сущностью. Участие слабой сущности в связи является полным, или обязательным. Подчеркнуть пунктиром частичный ключ, идентифицирующий слабую сущность.

Шаг 5: Определить связи между сущностями (одну или несколько), если таковые существуют.

Шаг 6: Определить на структурированном английском языке точный характер связей с обеих сторон. Например, связь A:B::1:M означает связь A с B вида один-ко-многим с одной стороны и связь B с A вида многие-к-одному с другой стороны.

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

Для связей вида обобщение/специализация определить их на структурированном английском, упомянув все сущности, участвующие в связи (подклассы и специализации). Указать существующие структурные ограничения.

Шаг 6a: Изучить список атрибутов и определить, есть ли среди них такие, которые идентифицируются двумя (или более) сущностями. Если таковые имеются, прикрепить их к соответствующей связи, соединяющей сущности.

Шаг 6b. Изучить диаграмму на наличие петель, указывающих на избыточные связи. Если связь действительно является избыточной, ее следует удалить.

Шаг 7: Привести пример данных.

Шаг 8: Представить «разработанную» базу данных пользователю, дополнив ее английским описанием всех сущностей, ключей, атрибутов и связей. Пересмотреть диаграмму в случае необходимости.

Контрольные вопросы 8.2

1. Чем отличаются правила преобразования для связи обобщение/специализация от правил преобразования для слабых сущностей?

2. Преобразуйте рисунок 8.4в реляционную базу данных и приведите пример данных.

Итоги главы

В этой главе обсуждались понятия специализации/обобщения. Также были рассмотрены понятия пересечения/непересечения. В данной главе были представлены EER-диаграммы, которые обсуждалисьElmasriиNavathe(2000),Connolly(1998). Некоторые авторы, напримерSanders(1995), используют варианты, близкие к этой модели, и называют связь специализация/обобщение связью "IsA". Здесь мы не обсуждаем "объединения" и "категории", "иерархии и решётки", которые являются дальнейшими расширениями связи специализация/обобщение и рассматриваются уElmasriиNavathe(2000).

Эта глава также включает разработку методологии EER-проектирования. Вследующей главемы обсудим преобразованиеERиEER-диаграмм в реляционную базу данных в процессе обратного проектирования.

Упражнения главы 8

Упражнение 8.1

Нарисуйте ERдиаграмму для библиотеки с сущностью «фонд библиотеки», включающей такие атрибуты как номер, название книги, автор(ы) и расположение в картотеке. Добавьте определяющий предикат «тип хранения» и изобразите непересекающиеся специализации с частичным участием – журналы и справочники, где журналы будут иметь атрибут «дата обновления», а справочники – «ограничения проверки». Преобразуйте эту связь в базу данных и приведите пример данных.

Упражнение 8.2

Изобразите ER-диаграмму для школьных компьютеров. Каждый компьютер идентифицируется по номеру, типу, модели, дате приобретения и месторасположению Имеются две категории для компьютеров – студенческие и служебные. Каждый студенческий компьютер имеет атрибут "часы работы". Каждый служебный компьютер имеет атрибут "ответственный человек" ("хозяин"). Преобразуйте эту связь в базу данных и приведите пример данных.

Список литературы

Connolly, T., Begg, C., and Strachan, A., Database Systems, A Practical

Approach to Design, Implementation, and Management, Addison-

Wesley, Harlow, England, 1998.

Elmasri, R and Navathe, S.B., Fundamentals of Database Systems, 3rd

ed., Addison-Wesley, Reading, MA, 2000.

Sanders, L., Data Modeling, Boyd & Fraser Publishing, Danvers, MA,

1995.

Teorey, T.J., Database Modeling and Design, Morgan Kaufman, San

Francisco,CA, 1999.

Учебный пример: Западно-Флоридский Торговый

Комплекс (продолжение)

До сих пор в нашем примере мы разрабатывали главные сущности и отношения и отображали их в реляционной базе данных (с некоторыми примерами данных). Тогда, после пересмотрения шага 7, который говорит:

Шаг 7. Представить «разработанную» базу данных пользователю, дополнив ее английским описанием всех сущностей, ключей, атрибутов и связей. Пересмотреть диаграмму в случае необходимости.

Предположим, что мы получили некоторую дополнительную информацию от пользователя:

СУБЪЕКТ может быть владельцем, служащим или менеджером. Для каждого СУБЪЕКТА мы будем записывать имя, номер социального страхования, адрес и телефон.

После рассмотрения этих дополнительных спецификаций, мы предложили одну новую сущность, СУБЪЕКТ.

Теперь, повторяем шаг 2 для СУБЪЕКТА:

Сущность

Эта база данных хранит информацию о СУБЪЕКТАХ. Для каждого СУБЪЕКТА в базе данных будем записывать его имя (pname), номер социального страхования (pssn), телефон (pphone) и адрес (padd).

Атрибуты для СУБЪЕКТА

Каждому СУБЪЕКТУ всегда будет соответствовать одно и только одно имя. Значение имени будет неделимо.

Каждому СУБЪЕКТУ всегда будет соответствовать один и только один номер социального страхования. Значение номера будет неделимо.

Каждому СУБЪЕКТУ всегда будет соответствовать один и только один номер телефона. Значение номера будет неделимо.

Каждому СУБЪЕКТУ всегда будет соответствовать один и только один адрес. Значение адреса будет неделимо.

Ключи

Для каждого СУБЪЕКТА предполагаем, что значению номера социального страхования будет уникальным для его идентификации

Эти сущности были добавлены в диаграмму на рисунке 8.5.

Рисунок 8.5. ER диаграмма для БД Западно-Флоридский Торговый Комплекс на данной стадии.

Используя шаг 6 для определения структурных ограничений связей, мы получаем:

На рисунке 8.5неперекрывающая связь между СУБЪЕКТОМ и МЕНЕДЖЕРОМ, ВЛАДЕЛЬЦЕМ и СЛУЖАЩИМ. Это означает, что человек может быть владельцем, менеджером или служащим (неперекрывающаяся связь обобщение/специализация).

Отобразим это отношение (с примерами данных):

Так как СУБЪЕКТ имеет поля с номером социального страхования, именем, адресом и телефоном, и так как субъект может быть владельцем, менеджером или служащим, здесь имеет место неперекрывающаяся связь отношение/специализация. Заметим, что мы удалили некоторые из атрибутов из исходных сущностей. Например, в сущности СЛУЖАЩИЙ нам не нужно содержать поле с информацией об имени служащего, потому что она может быть получена из сущности СУБЪЕКТ, в котором хранится номер служащего.

В итоге наша база данных будет спроектирована следующим образом (без данных):

MALL-Store

name	store_name

ТОРГОВЫЙ КОМПЛЕКС

name

address

МАГАЗИН

sloc

sname

snum

mall_name

so_ssn

sm_ssn

ВЛАДЕЛЕЦ

so_ssn

So_off_phone

ОТДЕЛ

dname

dnum

snum

СЛУЖАЩИЙ

essn

dnum

snum

dm_ssn

СУБЪЕКТ

pssn

pname

padd

sport

pphone

На этом заканчивается наш учебный пример.