Типы связей между таблицами (реляционные отношения между таблицами)

В существующих объектно-реляционных СУБД реально могут использоваться несколько типов связи между таблицами реляционной базы данных. При установлении связи между двумя таблицами одна из них являться главной (master) или родительской, а вторая — подчиненной (detail) или дочерней (зависимой). Механизм установления связей между таблицами основан на использовании первичных и внешних ключей таблиц. В подчиненной таблице всегда есть внешний ключ, значения которого должны (или могут) точно совпадать со значениями первичного ключа таблицы, являющейся главной по отношению к данной таблице. Каждая связь может иметь одну из двух модальностей — модальность «Может» и модальность «Должен». Модальность «Может» означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может и не быть связан ни с одним экземпляром (не жёсткая, или обычная связь)⁵. Модальность «Должен» означает, что экземпляр одной сущности должен быть обязательно связан не менее чем с одним экземпляром другой сущности (жёсткая связь). Причём изменение или удаление записи главной таблицы (если эти действия не запрещены) приведёт к изменению множества связанных с ней внешним ключом записей подчиненной таблицы (если такие есть), а изменение или удаление текущей записи в подчиненной таблице не вызовет никаких изменений в главной таблице⁶.

Рассмотрим основные типы связи между таблицами в реляционных и объектно-реляционных БД.

 Один к одному(1:1). Связь типа «один к одному» означает, что в каждый момент времени каждому экземпляру сущности А соответствует 0 или 1 экземпляров сущности В. Говоря на языке конкретной реализации сущностей в виде таблиц, если с конкретной строкой первой таблицы связано в каждый момент времени нуль строк или одна строка второй таблицы, то между ними установлена связь (установлено отношение) «один к одному». Говоря по другому, отношение один к одному имеет место, если одной записи родительской таблицы соответствует, или может соответствовать, одна запись в дочерней таблице.

Используя понятия ключей, тип связи между таблицами «один к одному» можно определить следующим образом: если одному значению первичного ключа главной (родительской) таблицы соответствуют 1, или 0 значений внешнего ключа подчинённой (дочерней) таблицы, то связь между этими таблицами имеет тип «один к одному».

В качестве примера отношения «один к одному» можно привести связь человека и номера паспор-та. Каждый человек может иметь только один паспорт, и в то же время паспорт принадлежит только одному человеку. В то же время, паспорт не может существовать сам по себе, хотя человек может не иметь паспорта (см. рис. 2). На рис.2 а) показана жёсткая связь «один к одному», а на рис. 2 б) не жёсткая связь «один к одному». Рассмотрим пример жёсткой связи «один к одному».

Первичным ключом таблицы 1 является атрибут Id (идентификатор человека) таблицы 1. Внеш-ним ключом таблицы 2 является атрибут Id (идентификатор человека) таблицы 2. Внешний ключ Id таблицы 2 ссылается на первичный ключ Id таблицы 1. То есть, родительской (главной) таблицей является таблица 1, а дочерней (подчинённой) – таблица 2. На рис 2 а) показан случай, когда между таблицей 2 и таблицей 1 установлена жёсткая связь «один к одному».

Таблица 1 Таблица 2

a). Жёсткая связь один к одному (модальность Должен)

Таблица 1 Таблица 2

б). Нежёсткая (обычная) связь один к одному (модальность Может)

Рис. 2 Пример жёсткой и нежёсткой связи типа «один к одному»

Чтобы установить жёсткую связь типа «один к одному» между таблицами 1 и 2, были выполнены следующие действия:

1. Было решено, что между таблицей 1 и таблицей 2 устанавливается связь.

2. Было решено, что в устанавливаемой связи между таблицами таблица 1 будет родительской (главной), а таблица 2 будет дочерней (подчинённой).

3. Было решено, что первичным ключом родительской таблицы 1, на который будет ссылаться внешний ключ дочерней таблицы 2, будет столбец (поле) Id таблицы 1.

4. Было решено, что для связи с родительской таблицей 1 в дочерней таблице 2 будет исполь-зоваться столбец Id, который для этой цели должен быть объявлен внешним ключом таблицы. Внешний ключ подчинённой таблицы 2 после установления связи между таблицами 1 и 2 должен будет ссылаться на первичный ключ главной таблицы 1.

5. В таблице 1 первичным ключом был объявлен столбец (поле) Id. При объявлении какого-то столбца таблицы первичным ключом для этого столбца автоматически устанавливаются свойства UNIQUE (уникальность значения каждого поля в столбце) и NOT NULL (значение поля в столбце не может быть равным NULL).

6. Была объявлена связь между таблицей 1 и таблицей 2, для которой были определены следу-ющие свойства:

- таблица 1 является родительской (главной);

- таблица 2 является дочерней (подчинённой);

- для связи со стороны родительской таблицы используется первичный ключ: поле Id таблицы 1;

- для связи со стороны дочерней таблицы используется поле Id таблицы 2 (при установлении это-

го свойства связи поле Id таблицы 2 автоматически объявляется внешним ключом таблицы 2);

- тип связи «один к одному»;

- модальность связи: Должен.

Для жёсткой связи «один к одному» характерно то, что каждой строке главной таблицы соответ-ствует ровно одна строка подчинённой таблицы.

В случае изображённой на рис. 2 б) обычной (не жёсткой) связи «один к одному» для таблицы 1 и таблицы 2 справедливо всё то, что было сказано о таблицах и установлении связи между ними в описании примера жёсткой связи «один к одному» за исключением того, что в свойствах связи между таблицами не была указана модальность Должен. В этом случае, «по умолчанию» установилась модальность связи Может.

Во всех СУБД всегда считается, что «по умолчанию» модальность связи между таблицами любого вида – Может. Поэтому далее, если вид модальности связи между таблицами не оговорен специально, будем считать, что модальность связи – Может.

Для случая обычной связи «один к одному» характерно, что количество строк подчинённой табли-цы не может быть больше, чем количество строк в главной таблице. Оно может быть меньшим, чем количество строк в главной таблице. Это происходит в том случае, когда каким-либо строкам главной таблицы не соответствует ни одной строки в подчинённой таблице. В показанном на рис 2 б) случае гражданин Петров не имеет паспорта. Поэтому строке, относящейся в главной таблице к гражданину Петрову, в подчинённой таблице не соответствует ни одна строка. Следовательно, количество строк в таблице 2 будет как минимум на 1 меньше, чем количество строк в таблице 1.

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

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

 Один ко многим (1:М). Связь типа «один ко многим» означает, что одному экземпляру сущности А соответствуют 0, 1 или несколько экземпляров сущности В. При этом сущность А называется роди-тельской сущностью, а сущность В — дочерней. Говоря на языке конкретной реализации сущно-стей в виде таблиц, если конкретная строка первой таблицы может быть связана с нулем, одной или несколькими строками второй таблицы, а несколько строк второй таблицы могут быть связаны с одной строкой первой таблицы, то между ними установлено отношение «один ко многим».

Используя понятия ключей, тип связи между таблицами «один ко многим» можно определить следующим образом: если одному значению первичного ключа главной (родительской) таблицы соответствуют одно, несколько, или 0 значений внешнего ключа подчинённой (дочерней) таблицы, то связь между этими таблицами имеет тип «один ко многим».

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

Ещё одним примером может служить связь рассмотренных ранее таблиц СТУДЕНТЫ (табл. 1) и УСПЕВАЕМОСТЬ (табл. 2), находящихся в одной базе данных БД (рис. 3).

В этом примере таблица СТУДЕНТЫ главная (родительская). Её первичный ключ состоит из одного атрибута «№_студенческого_билета». Таблица УСПЕВАЕМОСТЬ является подчинённой (дочерней). Её внешний ключ состоит из одного атрибута «№_студенческого билета». Внешний ключ дочерней таблицы ссылается на первичный ключ родительской таблицы. В результате, одной строке в таблице СТУДЕНТЫ (главной) могут соответствовать одна или несколько строк в таблице УСПЕВАЕМОСТЬ (подчинённой).

Таблица СТУДЕНТЫ Таблица УСПЕВАЕМОСТЬ

Рис. 3 Пример связи «один ко многим»

 Многие ко многим (M:N). Связь типа «многие ко многим» означает, что каждый экземпляр первой сущности может быть связан с нулем, одной или несколькими экземплярами второй сущности и каждый экземпляр второй сущности может быть связан с нулем, одной или несколькими экземпля-рами первой сущности. Или на языке конкретной реализации сущностей в виде таблиц: если каждой строке в первой таблице соответствует нуль, одна или несколько строк во второй таблице, и наобо-рот, то между ними установлено отношение «многие ко многим». Фактически, если между двумя таблицами А и В установлена связь типа «многие ко многим», это означает, что таблица А является главной по отношению к таблице В (таблица В - подчинённая) и, одновременно таблица В является главной по отношению к таблице А (таблица А – подчинённая). Со стороны таблицы А поддер-живается связь с таблицей В типа «один ко многим» и, одновременно, со стороны таблицы В под-держивается связь с таблицей А типа «один ко многим».

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

В качестве примера отношения «многие ко многим» можно рассмотреть связь служащего и про-екта. Каждый служащий может одновременно работать над несколькими проектами, и в то же время в каждом проекте могут участвовать несколько служащих (см. рис.4).

В таблице СЛУЖАЩИЕ хранятся данные о служащих, например, отдела. Строка каждого служа-щего в поле «Id_S» содержит его уникальный идентификатор служащего в списке отдела, а в полях «Id_p1», «Id_p2», «Id_p3» - уникальные идентификаторы проектов, в которых он участвует. В таблице ПРОЕКТЫ хранятся данные о проектах, над которыми работают сотрудники отдела. Каж-дый служащий не может участвовать более, чем в трёх проектах одновременно. В каждом проекте одновременно могут участвовать до пяти служащих.

Строка каждого проекта в поле «Id_p» содержит его уникальный идентификатор проекта в списке проектов, а в полях «Id_SP1», «Id_SP2», «Id_SP3», «Id_SP4», «Id_SP5» - уникальные идеентифика-торы сотрудников отдела, которые участвуют в его разработке. Связь «многие ко многим» установ-лена благодаря тому, что, с одной стороны атрибут Id_S таблицы СЛУЖАЩИЕ является первичным ключом этой таблицы и на него ссылаются внешние ключи таблицы ПРОЕКТЫ («Id_SP1», «Id_SP2», «Id_SP3», «Id_SP4», «Id_SP5»), а с другой стороны, атрибут Id_p таблицы ПРОЕКТЫ является первичным ключом этой таблицы и на него ссылаются внешние ключи таб-лицы СЛУЖАЩИЕ («Id_p1», «Id_p2», «Id_p3»).

Таблица СЛУЖАЩИЕ Таблица ПРОЕКТЫ

Рис. 4 Пример связи «многие ко многим»

Связь «многие ко многим» поддерживается на уровне ссылочной целостности и индексов лишь небольшим количеством объектно-реляционных СУБД (Oracle). Считается, что этот тип связи является временным типом связи, допустимым на ранних этапах разработки модели ИС. В дальнейшем этот тип связи должен быть заменен двумя связями типа «один ко многим» путём создания дополнительной (промежуточной) сущности (таблицы). Например, так, как показано на рис. 5.

Рис. 5. Преобразование типа связи «многие ко многим» в связи «один ко многим»

Между собой могут быть связаны и более, чем две таблицы (что обычно и бывает на практике). Одна и та же таблица может быть главной по отношению к одной таблице и подчиненной по отношению к другой. Или у одной главной таблицы может находиться в подчинении не одна, а несколько таблиц. Одна подчинённая таблица может управляться несколькими главными для неё таблицами (см. пример на рис.5 и рассмотренный ранее пример на рис.3, [3], стр.36). Таким образом, у главной таблицы может быть несколько подчиненных, и у подчинённой таблицы может быть несколько главных таблиц.

Первичный ключ таблицы может одновременно являться её внешним ключом. И наоборот, внеш-ний ключ таблицы может одновременно являться её первичным ключом (см. рис. 3).

Задание

Выберите из приведённой ниже таблицы номера вопросов, соответствующие номеру вашей подгруппы (бригады). В файле «Вопросы к LabRab 3st.doc» найдите вопросы, имеющие выбранные вами номера. Занесите в отчёт выбранные вопросы вместе со всеми приведёнными вариантами ответов. Отметьте любым образом только правильные варианты ответов на эти вопросы.

Номер подгруппы (бригады)	Номера вопросов в файле «Вопросы к LabRab 3st.doc»
1	16, 13, 11, 9, 5
2	26, 31, 3, 8, 13
3	15, 12, 9, 6, 10
4	28, 33, 5, 11, 17
5	19, 24, 29, 1, 6
6	18, 23, 28, 33,5
7	6, 11, 16, 21, 26
8	2, 7, 12,17, 22
9	23, 20, 17, 14, 18
10	14, 19, 24, 29, 1
11	1, 6, 11, 16, 21
12	32, 29, 26, 23, 27
13	3, 8, 13, 18, 23
14	11, 16, 21, 26, 31
15	31, 28, 25, 22, 26
16	10, 15, 20, 25, 30
17	22, 27, 32, 4, 9
18	7, 4, 1, 31, 2
19	31, 3, 8, 13, 18
20	27, 32, 4, 9, 14
21	24, 21, 18, 17, 19
22	21, 16, 13, 11, 8
23	23, 28, 33, 5, 11
24	16, 13, 11, 9, 5
25	5, 6, 33, 30, 1

Примечание: правильных или неправильных вариантов ответа на каждый вопрос может быть

несколько.

█

1 Тип данных столбца «№_студенческого билета» определен в описании домена №UD. Максимальная длина одного значения для типа данных «целочисленный» берётся «по умолчанию», которое определяется самим типом данных «целочисленный».

2 Тип данных столбца «Имя», максимальная длина одного значения (в количестве символов) и номер кодовой страницы символьных данных столбца определены в описании домена FNSN.

3 Для типов данных DATE и SMALLINT максимальная длина значений определена «по умолчанию» самими типами данных.

4 Следует помнить, что существуют реляционные СУБД, в которых не выполняются ограничения ссылочной целостности. Это, как правило, ранние разработки локальных реляционных СУБД — FoxPro версии 2.6 и ниже, версии dBase для DOS, Сlipper и Paradox для DOS.

5 Модальность Может (нежёсткая связь) поддерживается всеми реляционными и объектно-реляционными СУБД «по умолчанию».

6 Модальность Должен (жёсткая связь) не поддерживается реляционными СУБД и поддерживается не всеми объектно-реляционными СУБД. Она поддерживается, например, такими СУБД как Oracle и DB2, и не поддержи-вается такими СУБД как MS SQL-сервер, InterBase, MS Visual FoxPro.

7 По причине того, что на практике связь типа «один к одному» встречается достаточно редко, не во всех промышленных объектно-реляционных СУБД предусмотрена возможность явного определения связи между таблицами типа «один к одному». В таких СУБД при установлении связи между таблицами «по умолчанию» устанавливается связь типа «один ко многим». Но, существует возможность неявного определения типа связи между таблицами типа «один к одному». Для этого, после объявления того, что таблицы связаны друг с другом, необходимо для внешнего ключа подчинённой таблицы установить свойства UNIQUE (уникальность значения каждого поля в столбце) и NOT NULL (значение поля в столбце не может быть равным NULL). В этом случае установленный «по умолчанию» тип связи «один ко многим» автоматически преобразуется в тип связи «один к одному» модальности Может (установится обычная связь типа «один к одному).

В рассматриваемом нами случае, для столбца (поля) Id таблицы 2, который должен стать внешним ключом таблицы 2, надо было бы определить свойства UNIQUE и NOT NULL.

8 Связь типа «многие ко многим» редко встречается в практической работе с БД. Это связано с тем, что такой тип связи сложен для понимания, корректного определения и организации корректной обработки данных. Во многих промышленных объектно-реляционных СУБД просто невозможно определить тип связи «многие ко многим». Но в таких мощных СУБД как Oracle это сделать можно.