3. Типи зв’язків між таблицями.

Виходячи з вищесказаного, можна тепер визначити реляційну БД як набір відношень, зв'язаних між собою.

Зв'язок в даному випадку - це асоціювання двох або більше відношень БД, що не має зв'язків між відношеннями, має дуже просту структуру і повною мірою реляційною називатися не може. Проте одна з основних вимог до організації реляційної БД - це забезпечення можливості пошуку одних кортежів по значеннях інших, для чого необхідно встановити між ними зв'язки. А оскільки в реальних інформаційних системах часто містяться тисячі кортежів, то теоретично між ними може бути встановлене більше мільйона зв'язків. Наявність такої безлічі зв'язків і визначає складність реляційних моделей БД.

Існують наступні основні види зв'язків:

- один до одного;

- один до багатьом;

- багато до одного;

- багато до багатьом.

Зв'язок один до одного припускає, що в кожен момент часу кожному елементу (кортежу) А відповідає 0 або 1 елементів (кортежів) В (див. мал. 2). Наприклад, працівник отримує зарплату, і лише одну.

Мал.2 Зв'язок один до одного

Зв'язок "один до багатьох" полягає в тому, що в кожен момент часу кожному елементу (кортежу) А відповідає декілька елементів (кортежів) В (див. мал. 3): Як приклад можна сказати, що в будинку проживає багато мешканців.

Мал. 3. Зв'язок "один до багатьох"

Зв'язок "багато до одного" припускає, що в кожен момент часу безлічі елементів А відповідає 1 елемент В

Наприклад, декілька студентів є студентською учбовою групою (див. мал. 4).

Мал4. Зв'язок "багато до одного"

. Нарешті, зв'язок "багато до багатьох" полягає в тому, що в кожен момент часу безлічі елементів А відповідає безліч елементів В (див. мал. 5). На жаль, цей тип зв'язку в реляційних БД безпосередньо не підтримується. Прикладом такого зв'язку може служити той факт, що у студентів учбові заняття з дисциплін ведуть безліч викладачів.

Мал. 5. Зв'язок "багато до багатьох"

Крім вищеперелічених, ще можуть існувати множинні зв'язки між одними і тими елементами, тринарні зв'язки (див. мал. 6); які, можуть бути виражені через вже розглянуті.

Мал.6. Множинних і тринарні зв'язки

4.Цілісність даних

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

Кожне відношення володіє хоч би одним можливим ключем. Один з них береться за первинний ключ. При виборі первинного ключа слід віддавати перевагу нескладеним ключам або ключам складеним з мінімального числа атрибутів. Небажано також використовувати ключі з довгими текстовими значеннями (переважно використовувати цілочисельні атрибути). Так, для ідентифікації працівника можна використовувати або унікальний табельний номер або номер паспорта, або набір з прізвища, імені, по батькові і номера відділу.

Не допускається; щоб первинний ключ відношення, тобто будь-який атрибут, що бере участь в первинному ключі, приймав невизначене значення. В цьому випадку виникне суперечлива ситуація: з'явиться елемент первинного ключа, що не володіє унікальністю, тому за цим при проектуванні БД необхідно стежити особливо ретельно.

Тепер поговоримо про зовнішні ключі.

Варто мати на увазі, що якщо відношення С зв'язує відношення А і В, то воно повинне включати зовнішні ключі, відповідні первинним ключам відносин А і В, що представлене на мал.7. Таким чином, при розгляді проблеми вибору способу зв'язку відношень в БД виникає питання про те, які ж повинні бути зовнішні ключі. При цьому для кожного зовнішнього ключа необхідно вирішити проблему, пов'язану з можливістю (або неможливістю) появи в зовнішніх ключах невизначених значень (NULL-значень - значень атрибуту для відсутньої інформації). Іншими словами, чи може існувати деякий кортеж у відношенні, для якого невідомий кортеж в пов'язаному з ним відношенні.

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

- операція каскадується - тобто видалення кортежів у відношенні приводить до видалення відповідних кортежів в зв'язаному відношенні. Наприклад, видалення інформації про прізвище, імені і тому подібне співробітника в одному відношенні приводить до видалення інформації про його заробітну плату в іншому;

Мал. 7. Зовнішні ключі

- операція обмежується - тобто віддаляються лише ті кортежі, для яких зв'язаної інформації в іншому відношенні немає. Якщо така інформація є, то видалення здійснити не можна. Наприклад, видалення інформації про прізвище, імені і тому подібне співробітника можливо лише в тому випадку, якщо інформація про його заробітну плату в зв'язаному відношенні відсутня

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

Тут є ті ж можливості, як і при видаленні:

- операція каскадується - тобто при оновленні первинного ключа відбувається оновлення зовнішнього ключа в зв'язаному відношенні. Наприклад, оновлення первинного ключа у відношенні, де зберігається інформація про співробітника приводить до оновленні зовнішнього ключа у відношенні з інформацією про його заробітну плату;

- операція обмежується - тобто оновлюються лише ті первинні ключі, для яких зв'язаної інформації в іншому відношенні немає. Якщо така інформація є, то оновлення зробити не можна. Наприклад, оновлення первинного ключа у відношенні, де зберігається інформація про співробітника, можливо в тому разі. якщо інформація про його заробітну плату в зв'язаному відношенні відсутня.

Таким чином, для кожного зовнішнього ключа в БД повинні передбачатися не тільки атрибут або комбінація атрибутів, складових цей зовнішній ключ, і відношення, що ідентифікується цим ключем, але також і варіанти "поведінки" БД в розглянутих вище випадках.