1.4.3. Відношення "багато-до-багатьох"

На рис. 1.5 показаны таблиці, що знаходяться у відношенні "багато-до-багатьох". Кожній навчальній групі відповідає декілька викладачів. Кожен викладач може вести, по-перше, декілька різних предметів, і, по-друге, викладати в різних групах.

Таблиця "Навчальні групи і дисципліни” і Таблиця "Викладачі"

Група	Дисципліна	№ викладача		№ викладача	ПІБ викладача	Кафедра
ПС-1	Програмування	10	->	10	...	АСУ
ТІ-1	Програмування	12		12	...	АСУ
ПС-1	Системний аналіз	10		62	...	ФС
РТ-2	Філософія	62		78	...	АСУ
ПС-1	Соціологія	62		85	...	ЕП
...	...	...		...	...	...

Рис 1.5 Зв’язок "багато-до-багатьох"

Деякі СУБД не підтримують зв’язки " багато-до-багатьох" на рівні індексів и цілісності посилань (див. наст. підрозділ), хоча і дозволяють реалізовувати її в таблицях неявним чином. Вважається, що БД завжди можна перебудувати так, щоб будь-який зв’язок " багато-до-багатьох " була замінена на один або більше зв’язків " один-до-багатьох ".

1.4.4. Зв’язки між записами однієї таблиці

Між записами однієї таблиці також можуть існувати зв’язки, тобто одні записи можуть посилатися на інші.

Приклад. Нехай в реляційній БД необхідно зберігати деревоподібну структуру довільного рівня, наприклад, структуру організації (рис. 1.6.)

Департамент автоматизації

Технічне управління

Відділ мереж

Ремонтний відділ

АТС

Управління програмними засобами

Відділ експлуатації

Інформаційна група

Адміністративна група

Диспетчерське бюро

Відділ розробки

Рис. 1.6. Структура організації

У цьому випадку можна створити таблицю (рис. 1.7), у якій кожному підрозділу організації відповідає один запис. Цей запис посилається на запис, що відповідає підрозділу вищого рівня, до якого входить цей підрозділ. І лише у запису про підрозділ найвищого рівня немає такого посилання.

№ підрозділу Назва підрозділу № підрозділу вищого рівня

1 Департамент автоматизації

2 Технічне управління 1

3 Управління програмними засобами 1

4 Відділ мереж 2

5 Ремонтний відділ 2

6 АТС 2

7 Відділ експлуатації 3

8 Відділ розробки 3

9 Інформаційна група 7

10 Адміністративна група 7

11 Диспетчерське бюро 10

Рис. 1.7. Табличне зображення структури організації

1.5. Цілісність посилань (referencial integrity)

Розглянемо найпопулярніший у базах даних зв’язок "один-до-багатьох" (рис. 1.8).

Таблиця “Товари”

Товар	Од. вим.	Ціна од.
Цукор	кг	4
Макарони	кг	5
Сіль	кг	1
Живчик	бут. 2 л.	5

Таблиця “Відпуск товарів”

Товар	Дата	Кількість (од.)
Цукор	10.02.07	100
Цукор	12.02.07	200
Цукор	14.02.07	50
Макарони	11.02.07	100
Макарони	12.02.07	50
Живчик	10.02.07	200
Живчик	12.02.07	300

Рис. 1.8 Зв’язані таблиці БД

Зауважимо, що дочірня та батьківська таблиці пов’язані між собою за спільним полем "Товар". Назвемо це поле полем зв’язку.

Можливими є два види змін, які призведуть до втрати зв’язків між записами у батьківській і дочірній таблицях:

• зміна значення поля зв’язку в запису батьківської таблиці без зміни значень полів зв’язку у відповідних записах дочірньої таблиці;

• зміна значення поля зв’язку в одному з записів дочірньої таблиці без відповідної зміни значення полів зв’язку в батьківській та дочірній таблицях.

Розглянемо перший випадок. На рис. 1.9 показано зміну значення поля "Товар" з "Цукор" на "Рафінад" в таблиці "Товари". В таблиці "Відпуск товарів" значення поля зв’язку "Цукор" не змінилось. В результаті:

- в дочірній таблиці "Відпуск товарів" для товара "Рафінад" (таблиця "Товари") немає відомостей про його відпуск зі складу;

- деякі записи таблиці "Відпуск товаров" містять відомості про відпуск товару ("Цукор"), про який немає інформації в таблиці "Товари".

Таблиця “Товари”

Товар	Од. вим.	Ціна од.
Рафінад	кг	4
Макарони	кг	5
Сіль	кг	1
Живчик	бут. 2 л.	5

Таблиця “Відпуск товарів”

Товар	Дата	Кількість (од.)
Цукор	10.02.07	100
Цукор	12.02.07	200
Цукор	14.02.07	50
Макарони	11.02.07	100
Макарони	12.02.07	50
Живчик	10.02.07	200
Живчик	12.02.07	300

Рис. 1.9 Порушення цілісності БД: записи з товаром “Цукор” (таблиця “Відпуск товарів”) не мають батьківського запису

Розглянемо другий випадок. Нехай в одному записі таблиці "Відпуск товарів" значення поля зв’язку "Цукор" змінилось на "Рафінад" (рис. 1.10). В результаті:

- в дочірній таблиці "Відпуск товарів" недостовірні відомості про відпуск зі складу товару "Цукор" (таблиця "Товари");

- один із записів таблиці "Відпуск товаров" містить дані про відпуск товару ("Рафінад"), відомості про який відсутні у таблиці "Товари".

І в першому, і другому випадках ми спостерігаємо порушення цілісності бази даних, це означає, що інформація в ній стає недостовірною. СУБД звичайно блокує дії, які порушують цілісність зв’язків між таблицями, тобто цілісність посилань. Коли говорять про цілісність посилань, мають на увазі сукупність зв’язків між окремими таблицями в усій БД. Порушення хоча б одного такого зв’язку робить інформацію в БД недостовірною.

Таблиця “Товари”

Товар	Од. вим.	Ціна од.
Цукор	кг	4
Макарони	кг	5
Сіль	кг	1
Живчик	бут. 2 л.	5

Таблиця “Відпуск товарів”

Товар	Дата	Кількість (од.)
Рафінад	10.02.07	100
Цукор	12.02.07	200
Цукор	14.02.07	50
Макарони	11.02.07	100
Макарони	12.02.07	50
Живчик	10.02.07	200
Живчик	12.02.07	300

Рис. 1.10 Порушення цілісності БД: запис з товаром “Рафінад” (таблиця “Відпуск товарів”) не мають батьківського запису

Щоб попередити втрату цілісності посилань, використовують механізм каскадних змін. Він передбачає такі дії:

• при зміні поля зв’язку в запису батьківської таблиці, слід синхронно змінити значення полів зв’язку у відповідних записах дочірньої таблиці;

• при вилученні запису у батьківській таблиці, слід вилучити відповідні записи в дочірній таблиці.

Зміни або вилучення у записах дочірньої таблиці при одночасній зміні (вилученні) запису батьківської таблиці називаються каскадними змінами і каскадними вилученнями.

Існує інший різновид каскадного вилучення: при вилученні батьківського запису в записах дочірніх таблиць значення полів зв’язку онулюються. Цей різновид застосовується рідко.

Звичайно для реалізації цілісності посилань в дочірній таблиці створюють зовнішній ключ, у який входять поля дочірньої таблиці. Цей ключ для дочірньої таблиці є первинним і тому за складом полів повинен збігатись з первинним ключем батьківської таблиці, або рідше – з частиною первинного ключа.