Базы данных: конспект лекций - Коллектив авторов (мир книг .TXT) 📗
На концах обеих этих не полностью идентифицирующих связей проставлены кратности «один» и «много». Это сделано для того, чтобы показать (как и в примере о врачах и пациентах) разницу, между упоминанием кода заказчика или исполнителя в разных классах сущностей. Действительно, в классе сущностей «График» любой код заказчика или исполнителя может встречаться сколь угодно много раз. Поэтому на этом, дочернем, конце связи стоит кратность «много». А в классе сущностей «Заказчики» или «Исполнители» каждый из кодов соответственно заказчика или исполнителя может встречаться один и только один раз, ведь эти классы сущностей являются каждый не чем иным, как полным списком всех заказчиков и исполнителей. Поэтому на этом, родительском конце связи, и стоит кратность «один».
И, наконец, заметим, что третья связь, а именно связь класса сущностей «График» с классом сущностей «Консультанты», является не обязательно не идентифицирующей.
Действительно, ведь в этом случае речь идет о переносе ключевого атрибута «Код консультанта» класса сущностей «Консультанты» в одноименный неключевой атрибут класса сущностей «График», т. е. первичный ключ класса сущностей «Консультанты» в классе сущностей «График» не идентифицирует первичного ключа уже этого класса. И, кроме того, как уже было упомянуто ранее, атрибут «Код консультанта» допускает Null-значения, поэтому здесь и используется именно не полностью не идентифицирующая связь. Таким образом, атрибут «Код консультанта» приобретает статус внешнего ключа и ничего более того.
Также обратим внимание на кратности связей, поставленных на родительском и дочернем концах этой не полностью не идентифицирующей связи. На ее родительском конце стоит кратность «не более одного». Действительно, если вспомнить определение не полностью не идентифицирующей связи, то мы поймем, что атрибуту «Код консультанта» из класса сущностей «График» не может соответствовать более одного кода консультанта из списка всех консультантов (которым является класс сущностей «Консультанты»). Да и вообще может так получиться, что ему не будет соответствовать ни одного кода консультанта (вспомним о флажке допустимости Null-значений Код консультанта: Null), ведь по условию присутствие консультанта на встрече заказчика и исполнителя, вообще говоря, не обязательно.
4. Обобщения
Очередным видом связи классов сущностей между собой, который мы рассмотрим, является связь вида обобщение. Это также нерекурсивный вид связи.
Итак, связь типа обобщение реализуется как взаимосвязь одного родительского класса сущностей с несколькими дочерними классами сущностей (в отличие от предыдущей рассмотренной связи Ассоциации, в которой речь шла о нескольких родительских классах сущностей и одним дочернем классе сущностей).
При формулировании правил представления данных при помощи связи Обобщения необходимо сразу сказать, что эта взаимосвязь одного родительского класса сущностей и нескольких дочерних классов сущностей, описывается полностью идентифицирующими связями, т. е. категориальными связями. Вспоминая определение полностью идентифицирующих связей, мы приходим к выводу, что при использовании Обобщения каждый атрибут первичного ключа родительского класса сущностей переносится в состав первичного ключа классов сущностей дочерних, т. е. атрибуты первичного мигрирующего ключа родительского класса сущностей полностью формируют первичные ключи всех дочерних классов сущностей, они их идентифицируют.
Любопытно отметить, что при Обобщении реализуется так называемая иерархия категорий или иерархия наследования.
При этом родительский класс сущностей определяет класс обобщенных сущностей, характеризующийся атрибутами, общими для сущностей всех дочерних классов или так называемых категориальных сущностей т. е. родительский класс сущностей представляет собой буквальное обобщение всех своих дочерних классов сущностей.
В качестве примера реализации обобщения в реляционной модели данных построим следующую модель. Эта модель будет основана на обобщенном понятии «Учащиеся» и будет описывать следующие категориальные понятия (т. е. будет обобщать следующие дочерние классы сущностей): «Школьники», «Студенты» и «Аспиранты».
Итак, построим ключевую диаграмму, отражающую суть взаимоотношений между родительским классом сущности и дочерними классами сущностей, описываемых связью типа Обобщение.
Итак, что же мы видим?
Во-первых, каждому из базовых отношений (или из классов сущностей, что одно и то же) «Школьники», «Студенты» и «Аспиранты» соответствуют свои собственные атрибуты, как то «Класс», «Курс» и «Год обучения». Каждый из этих атрибутов характеризует участников своего собственного класса сущностей. Еще мы видим, что первичный ключ родительского класса сущностей «Учащиеся» мигрирует в каждый дочерний класс сущностей и формирует там первичный внешний ключ. При помощи этих связей мы можем по коду любого учащегося определить его имя, фамилию и отчество, информацию о которых мы не найдем в самих соответствующих дочерних классах сущностей.
Во-вторых, так как мы говорим о полностью идентифицирующей (или категориальной) связи классов сущностей, то обратим внимание на кратности связей между родительским классом сущностей и его дочерними классами. На родительском конце каждой из этих связей стоит кратность «один», а на каждом дочернем конце связей стоит кратность «не более одного». Если вспомнить определение полностью идентифицирующей связи классов сущностей, то становится понятно, что действительно единственный в своем роде код учащегося, являющийся первичным ключом класса сущностей «Учащиеся», задает не более одного атрибута с таким кодом в каждом дочернем классе сущностей «Школьники», «Студенты» и «Аспиранты». Поэтому все связи имеют именно такие кратности.
Запишем фрагмент операторов создания базовых отношений «Школьники» и «Студенты» с определением правил поддержания ссылочной целостности типа cascade. Итак, имеем:
Create table Школьники
…
primary key (Код ученика)
foreign key (Код ученика) references Учащиеся (Код ученика)
on update cascade
on delete cascade
Create table Студенты
…
primary key (Код студента)
foreign key (Код студента) references Учащиеся (Код студента)
on update cascade
on delete cascade;
Таким образом, мы видим, что в дочернем классе сущностей (или отношений) «Школьники» задается первичный внешний ключ, ссылающийся на родительский класс сущностей (или отношение) «Учащиеся». Правило cascade поддержания ссылочной целостности определяет, что при удалении или при обновлении атрибутов родительского класса сущностей «Учащиеся» соответствующие им атрибуты дочернего отношения «Школьники» будут автоматически (каскадом) обновляться или удаляться. Аналогично при удалении или при обновлении атрибутов родительского класса сущностей «Учащиеся» соответствующие им атрибуты дочернего отношения «Студенты» также будут автоматически обновляться или удаляться.
Необходимо заметить, что здесь используется именно это правило поддержания ссылочной целостности, потому что в данном контексте (перечень учащихся) не рационально запрещать удаление и обновление информации, а также присваивать неопределенное значение вместо реальных сведений.
А теперь приведем пример классов сущностей, описанных в предыдущей диаграмме, только представленных в табличной форме. Итак, имеем следующие таблицы-отношения:
Учащиеся – родительское отношение, объединяющее в себе информацию об атрибутах всех остальных отношений:
Школьники – дочернее отношение:
