2.2 Ключевые поля и связи

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

Первичный ключ не должен иметь дополнительных атрибутов, то есть если из него исключить произвольный атрибут, оставшихся атрибутов будет недостаточно для однозначной идентификации отдельных кортежей. По способу задания первичных ключей различают логические (естественные) ключи и суррогатные (искусственные). При проектировании базы данных «Кафедры ВУЗа» использовались суррогатные ключи.

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

Аналогично выделяются первичные ключи остальных сущностей:

• «Учебно-методические пособия» - «№ пособия»;

• «Дисциплины» – «№ дисциплины»;

• «Учебные планы» – «№ плана»;

• «Преподавательские поручения» – «№ поручения»;

• «Штатное расписание» – «Табельный №»;

• «Звания» – «Код звания»;

• «Руководительская работа» – «№ работы».

Кроме того, для организации связей подчиненности между таблицами выделяют так называемые внешние ключи – это первичные ключи других таблиц. Так «Дисциплины», «Учебно-методические пособия» и «Штатное расписание» обозначают сущность «Кафедры», и содержат внешний ключ «№ кафедры», являющийся первичным ключом последней. Внешним ключом сущности «Руководительская работа» является «Табельный №», «Учебный план» – «№ дисциплины». Сущность «Преподавательские поручения» связывает сущности «Учебные планы» и «Штатное расписание» и содержит два внешних ключа: «№ плана» и «Табельный №».

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

Отношение «один-ко-многим» является наиболее часто используемым типом связи между таблицами. В отношении «один-ко-многим» каждой записи в таблице A могут соответствовать несколько записей в таблице B, но запись в таблице B не может иметь более одной соответствующей ей записи в таблице A.

При отношении «многие-ко-многим» одной записи в таблице A могут соответствовать несколько записей в таблице B, а одной записи в таблице B несколько записей в таблице A, при этом записи таблицы А связаны с записями таблицами В через записи таблицы С.

При отношении «один-к-одному» каждая запись в таблице A может иметь не более одной связанной записи в таблице B и наоборот. Отношения этого типа используются не очень часто, поскольку большая часть сведений, связанных таким образом, может быть помещена в одну таблицу.

Рассмотрим модель проектируемой базы данных. Она содержит таблицы кафедр учебного заведения, дисциплин, сотрудников кафедр, учебных пособий. В состав кафедры входит более чем пять сотрудников, она может читать множество дисциплин и издавать большое количество учебных пособий по этим дисциплинам. Следовательно, связь между таблицами «Кафедры», «Дисциплины», «Учебно-методические пособия» и «Штатное расписание» представляет собой отношение «одик-ко-многим».

Аналогично этому устанавливается связь «один-ко-многим» между таблицами «Дисциплины», «Учебные планы», «Преподавательские поручения» и «Штатное расписание». Одна дисциплина может преподаваться на различных специальностях разных форм обучения в нескольких семестрах, кроме того на основе одного учебного плана по дисциплине могут быть составлены несколько преподавательских поручений, и, наконец, один преподаватель может преподавать несколько дисциплин, т.е. получить несколько преподавательских поручений.

Связь «один-ко-многим» между таблицами «Штатное расписание» и «Руководительская работа» объясняется тем, что у одного преподавателя может быть в подчинении несколько студентов, занимающихся научно-исследовательской работой.