Презентація на тему:
Створення зв'язків між таблицями

Спецкурс “Основи баз даних” Розділ 5. Створення зв'язків між таблицями За підручником І. О. Завадського

Повторення Які різновиди зв'язків існують між сутностями предметної області? Як визначити різновид зв'язку? Що таке обмеження цілісності? Сформулюйте головний принцип семантичного моделювання.

Мотивація вивчення теми уроку Модель «сутність-зв'язок» складається з таких основних елементів, як сутності і зв'язки. Сутностям у базі даних відповідають таблиці, які ви навчилися створювати на попередньому уроці. Сьогодні ви дізнаєтеся, як створювати зв'язки між таблицями. Отже, опрацювавши матеріал цього розділу, ви вмітимете відображати в базі даних модель «сутність-зв'язок» у цілому.

Створення зв'язку «один-до-багатьох» Кожен із цих типів зв'язків у СКБД реалізують по-своєму. Почнемо із найпоширенішого типу зв'язку — «один-до-багатьох».

Створення зв'язку між таблицями Учні та Класи В базі даних школа ви створили таблиці учнів, класів і вчителів. У таблицю класів ви ввели інформацію про три класи (10А, 11А та 11Б), а в таблицю учнів — про чотирьох учнів. Але інформацію про те, який учень у якому класі вчиться, ви не вводили. Уважно подивившись на поля таблиць Учні та Класи, ви побачите, що таку інформацію просто немає куди вводити: поля прізвище, ім’я або дата народження таблиці Учні не призначено для зберігання цих даних, так само як і поле назва таблиці Класи. Відомості про те, хто в якому класі вчиться, важливі і, очевидно, десь мають зберігатися. Теорія реляційних баз даних пропонує доволі просте рішення: у таблиці Учні потрібно створити додаткове поле клас, у яке і ввести назву класу кожного учня.

Після внесення необхідних змін таблиці Учні та Класи мають набути такого вигляду, як показано на рис.

Отже, поле клас, додане до таблиці Учні, стало тим засобом, за допомогою якого ми реалізували в базі даних зв'язок «учень вчиться у класі». Це зв'язок між сутностями Учень і Клас, що в моделі «сутність-зв'язок» виглядає так, як на рис. 2. Значення в доданому полі зберігають інформацію про зв'язки між об'єктами: конкретними учнями та класами. На рис.1 стрілками показано, з яким об'єктом Клас пов'язано кожен об'єкт Учень. Рис.1 вчиться Рис.2 1 Зв'язок між сутностями Учень і Клас у моделі «сутність-зв'язок»

До уваги! Зауважте, що додаткові поля, призначені для збереження інформації про зв'язки, на моделі «сутність-зв'язок» не відображаються. Це пояснюється тим, що за допомогою додаткових полів зв'язки реалізують тільки в реляційних БД, а модель «сутність-зв'язок» від специфіки моделі даних абстрагована, вона може використовуватися в нереляційних БД і навіть не в базах даних взагалі. Збереження інформації про зв'язки об'єктів у додаткових полях є однією з визначальних рис, що відрізняють реляційні БД від усіх інших. У ієрархічних, мережевих та об'єктно-орієнтованих БД об'єкт «учень» містив би вказівник на те місце в пам'яті, де зберігається об'єкт «клас», тобто зв'язки в цих БД реалізують явно. У реляційній БД об'єкт «учень» містить лише значення 10А, яке безпосередньо ні на що не вказує; щоб отримати відомості про такий клас, його потрібно ще знайти в таблиці Класи. Отже, в реляційних БД зв'язки між об'єктами реалізують неявно.

Завдання 5.1 У таблиці Учні створіть поле клас того ж типу і з тими ж параметрами, що і поле назва в таблиці Класи, і введіть зазначені вище дані про навчання учнів у класах.

Створення зв'язку «один-до-багатьох»: загальний випадок Задамося питанням: чому для реалізації зв'язку «учень вчиться у класі» ми створювали додаткове поле клас у таблиці Учні, а не поле учень у таблиці Класи? Відповідь знайти не важко, якщо звернути увагу на тип цього зв'язку. Ми створили додаткове поле в таблиці Учні тому, що учень може вчитися тільки в одному класі, і не створювали його в таблиці Класи тому, що в класі може вчитися багато учнів. Справді, щоб зберегти в таблиці Класи відомості про навчання учнів у певному класі, довелося б для першого учня створювати додаткове поле учень1, для другого — учень2 і т. д. Неефективність такого підходу очевидна, а коли врахувати той факт, що кількість учнів у класах може бути різною, реалізувати подібне рішення виявиться взагалі неможливо.

Створення зв'язку «один-до-багатьох»: загальний випадок Тепер припустимо, що таблиця Класи містить ще атрибут профіль (за його допомогою вказують, що клас філологічний, математичний тощо). Тоді які значення, назви чи профілі класів, потрібно вводити в поле клас таблиці Учні? Очевидно, що все одно назви, оскільки профіль не ідентифікує клас (наприклад, якщо вказати, що Шпак Максим вчиться у математичному класі, залишиться незрозумілим, у якому саме: десятому, одинадцятому чи якомусь іншому). Нагадаємо, що ідентифікувати об'єкти дозволяють значення ключових полів і саме тому, що поле назва є ключем у таблиці Класи, його значення потрібно вводити в додаткове поле клас таблиці Учні. Поля, що містять значення ключів інших таблиць, називають зовнішніми ключами. Наприклад, поле клас — це зовнішній ключ таблиці Учні. Кажуть, що зовнішній ключ посилається на таблицю, значення ключа якої він містить. Так, зовнішній ключ клас посилається на таблицю Класи. Ключ таблиці називають також первинним ключем, щоб підкреслити його відмінність від зовнішнього ключа.

Зовнішній ключ Підсумовуючи сказане, сформулюємо правило моделювання зв'язку «один-до-багатьох» у реляційній базі даних. Щоб у реляційній базі даних реалізувати зв'язок «один-до-багатьох», зображений на рис. а (кожному об'єкту А може відповідати багато об'єктів В, але кожному об'єкту В — лише один об'єкт А), у таблиці В потрібно створити зовнішній ключ, який посилатиметься на таблицю А Зовнішній ключ — це поле або набір полів, значення яких повинні належати множині значень первинного ключа деякої іншої таблиці. Зв'язок «один-до-багатьох»: а — зображення в моделі «сутність-зв'язок»; б — реалізація в базі даних а б

Графічне подання зв'язків у Microsoft Access На стрічці Робота з базами даних Access 2007 є кнопка Схема даних, за допомогою якої схему бази даних можна зобразити графічно. Якщо клацнути цю кнопку, буде відображено вікно Схема даних під час першого використання.

Графічне подання зв'язків у Microsoft Access У вікні Добавление таблицы потрібно, утримуючи клавішу CTRL або SHIFT, виділити назви всіх таблиць і клацнути кнопку Добавить. У результаті всі таблиці буде відображено у вікні Схема данных. Вміст вікна можна редагувати: щоб видалити зображення таблиці, клацніть його правою кнопкою миші та виберіть у контекстному меню команду Скрыть таблицу, а щоб додати, скористайтеся кнопкою Відобразити таблицю.

Зв'язки між таблицями у вікні Схема данных зображуються з'єднувальними лініями. Ці лінії з'єднують не просто зображення таблиць, а ті поля, за допомогою яких реалізується зв'язок. Зв’язок “один-до-багатьох” реалізують за допомогою ключового поля однієї таблиці та зовнішнього ключа до іншої. Саме ці поля потрібно з'єднати лінією у вікні Схема данных. Для цього слід клацнути ключове поле(назву такого поля записано жирним шрифтом) і, не відпускаючи лівої кнопки миші, перетягнути його на зовнішній ключ. Відкриється вікно Изменение связей, у якому достатньо лише клацнути кнопку Создать — і зв'язок буде відображено.

Проаналізуємо вміст вікна Изменение связей детальніше. У нижній його частині зазначено тип зв'язку (один-ко-многим), а зверху містяться два списки Таблица/запрос та Связанная таблица/запрос. У першому відображаються назви ключових полів таблиці, що перебуває на кінці зв'язку «один» (вона називається головною), а в другому — зовнішній ключ таблиці, що перебуває на кінці зв'язку «багато» (вона називається зв'язаною). За потреби поля, через які встановлюється зв'язок, можна змінити, клацнувши кнопку справа від назви ключового поля або зовнішнього ключа. Параметри зв'язку можна змінити після його створення. Для цього слід двічі клацнути лінію зв'язку і задати необхідні параметри у вікні Изменение связей.

Забезпечення цілісності даних У новостворене поле клас таблиці Учні ми вводили назви класів з таблиці Класи, але СКБД дозволяє вводити в це поле майже будь-які дані, навіть назву неіснуючого у школі класу або, скажімо, слово Привіт. Звісно, такі дані будуть некоректними, адже учень не може вчитися в 21Ш класі або у класі Привіт. Щоб гарантувати цілісність даних, СКБД має стежити за дотриманням простого правила: у поле клас таблиці Учні неможна вводити значення, яких немає у полі назва таблиці Класи.

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

Щоб примусити СКБД стежити за дотриманням цього обмеження цілісності, під час створення зв'язку у вікні Изменение связей слід встановити прапорець Обеспечение целостности данных. Якщо ви це зробите, то спроба ввести в поле клас таблиці Учні значення на кшталт 21Ш призведе до відображення повідомлення про помилку. На схемі даних у Microsoft Access лінії зв'язків з підтримкою цілісності вирізняються тим, що біля їхніх кінців зображуються символи множинності (1 або ), так само, як на моделі «сутнісь-зв'язок. 1

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

Порушення обмежень цілісності 3). Після створення зв'язку змінюють значення ключа головної таблиці. Зовнішній ключ зв'язаної таблиці після таких змін може порушувати обмеження цілісності. Microsoft Access дає змогу вирішити цю проблему двома шляхами: Якщо під час створення зв'язку у вікні Изменение связей не було встановлено прапорець каскадное обновление связанных полей, зміни буде заблоковано; якщо прапорець каскадное обновление связанных полей встановлено, СКБД здійснить каскадне оновлення: значення зовнішнього ключа буде змінено так само, як змінилися значення первинного ключа головної таблиці. 4). Після створення зв'язку запис головної таблиці видаляють. У цьому випадку може бути здійснено каскадне видалення даних: записи зв'язаної таблиці, що відповідають видаленому запису головної таблиці, також автоматично видалятимуться. Каскадне видалення здійснюється, якщо під час створення зв'язку у вікні Изменение связей було встановлено прапорець каскадное удаление связанных полей. Якщо прапорець знято, видалення блокуватиметься.

Завдання 5.2 Відобразіть зв'язок між таблицями Класи та Учні у вікні Схема данных і забезпечте підтримку цілісності даних.

Створення зв'язку «багато-до-багатьох» Для моделювання зв'язку «учень вчиться у класі» зовнішній ключ неможна створювати в таблиці Класи, оскільки клас зв'язаний з багатьма учнями. Тож як бути у випадку зв'язку «багато-до-багатьох», наприклад зв'язку «учитель викладає в класі»? Адже подібні міркування приводять до висновку, що зовнішній ключ неможна створювати в жодній з двох таблиць-учасниць зв'язку. Насправді так і є: зв'язок «багато-до-багатьох» моделюють за допомогою додаткової таблиці, де і створюють зовнішні ключі. Щоб у реляційній базі даних змоделювати зв'язок «багато-до-багатьох» між таблицями А і В, потрібно створити додаткову таблицю С, а в ній — два зовнішніх ключі, що посилатимуться на таблиці А і В. Зв'язок «багато-до-багатьох»: а - зображення в моделі «сутність-зв'язок»; б - реалізація в базі даних а б

Для моделювання зв'язку “учитель викладає в класі” ми створюємо таблицю Викладання з двома полями учитель і клас. Поле учитель буде зовнішнім ключем, що посилається на таблицю Учителі, а поле клас – зовнішнім ключем, що посилається на таблицю Класи. Для зберігання інформації про те що вчитель Сошко Катерина Миколаївна викладає у 10 А та 11 А класах, у таблиці викладання необхідно створити два записи: у одному зазначити номер паспорта цієї вчительки (СР 652320 та назву класу 10 А, а в іншому - той самий номер паспорта та назву класу 11 А. У такий спосіб у таблицю Викладання можна ввести інформацію про викладання одного вчителя в кількох класах. Нічого не завадить ввести в цю таблицю й інформацію про викладання в одному класі кількох учителів. Наприклад, у 10 А класі викладають вчителі з паспортами СР 652320 та СО 927453. Таким чином, допоміжна таблиця дозволила зв'язати учителя з багатьма класами, а клас – з багатьма учителями. У підсумку це і є зв'язком «багато-до-багатьох» між таблицями Учителі та Класи.

Моделювання зв'язку вчителя з класами

У таблиці Викладання, як і в будь-якій іншій, варто створити первинний ключ. Поле учитель не є ключем, оскільки його значення можуть повторюватися. Те саме можна сказати і про поле клас. Але пара значень атрибутів учитель, клас повторюватися не повинна. Отже, у таблиці Викладання ключ складається з двох полів. Створення цього ключа гарантуватиме, що інформація про викладання вчителя X у класі Y зберігатиметься лише в одному записі, і це узгоджується з головним принципом семантичного моделювання. Для створення ключа з кількох полів потрібно у вікні конструктора таблиці виділити їх усі, утримуючи клавішу Ctrl, після чого клацнути кнопку .

Щоб зобразити зв'язок «учитель викладає у класі» графічно, у вікні Схема данных необхідно з'єднати ключі таблиць Учителі та Класи із відповідними зовнішніми ключами таблиці Викладання. Варто також подбати про забезпечення цілісності даних для цих зв'язків. У результаті ви маєте отримати схему: Зв'язок «багато-до-багатьох» на схемі даних 1 1

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

Завдання 5.3 Промоделюйте в базі даних школа зв'язок “учитель викладає в класі”: створіть таблицю Викладання з зовнішніми ключами учитель і клас, типи яких мають бути такими ж, як типи первинних ключів таблиць Учителі і Класи. Уведіть такі дані: Сошко Катерина Миколаївна викладає у 10А та 11А класах; Михайлюк Дмитро Семенович викладає в 11Б класі; Корбут Василь Петрович викладає в 11А і 11Б класах; Томчишин Віктор Георгійович викладає в 11А класі; Петрова Ніна Володимирівна викладає в 10А, 11А і 11Б класах. Номери паспортів учителів не вводьте з клавіатури, а копіюйте з таблиці Учителі. Зобразіть зв'язок у вікні Схема данных та забезпечте підтримку цілісності даних.

Створення зв'язку «один-до-одного» Зв'язок «один-до-одного», так само як і зв'язок «один-до-багатьох», створюють із використанням зовнішнього ключа. Але у зв'язку «один-до-одного» зовнішній ключ має специфічну властивість: його значення не повинні повторюватися. Щоб пояснити цю тезу, звернімося знову до рис., де проілюстровано зв'язок «один-до-багатьох». Один запис таблиці Класи міг бути зв'язаний з багатьма записами таблиці Учні саме тому, що в таблиці Учні значення зовнішнього ключа могли повторюватися (наприклад, значення 11Б на рис. у таблиці Учні ми бачимо двічі). Якщо заборонити такі повтори, то кожен клас буде зв'язаний не більше, ніж з одним учнем, тобто ми реалізуємо зв'язок «один-до-одного».

До уваги! Індексовані поля, або поля з індексами, -один з найважливіших механізмів реляційних СКБД, який дозволяє кардинально прискорити пошук даних. Індекс -це відсортована послідовність значень одного або кількох полів. Якби індексів не було, то для пошуку заданого значення у певному полі системі довелося б перевіряти всю таблицю, що нерідко містить мільйони записів. Але відсортованість індексу дозволяє знаходити задане значення серед мільйона інших усього за допомогою 20 операцій порівняння.

Під час побудови зв'язку «один-до-багатьох» зовнішній ключ ми створювали в тій таблиці, що розташована з боку «багато». Коли ж ідеться про зв'язок «один-до-одного», зовнішній ключ можна створювати в будь-якій таблиці. Розглянемо зв'язок «учитель є класним керівником» і припустимо, що зовнішній ключ міститиметься в таблиці Класи. Визначимо, у який спосіб його краще створити: вважати зовнішнім первинний ключ (поле назва) чи створити для нього додаткове поле. Якщо обрати перший спосіб, то значення з поля назва мають міститися і в полі паспорт таблиці Учителі, що суперечить здоровому глузду. Отже, зовнішній ключ може розміщуватися лише в додатковому полі. Якщо зовнішній ключ створювати в таблиці Учителі, висновок буде той самий: поле паспорт не може містити назв класів, а отже, бути зовнішнім ключем.

Таким чином, для зовнішнього ключа в одній із таблиць необхідно створити додаткове поле. Нехай це буде таблиця Класи, а поле називатиметься класний керівник. Коли ви створюватимете це поле в режимі конструктора таблиці, в області властивостей поля зі списку Индексированное поле слід вибрати елемент Да (совпадения не допускаются) - саме це дозволить створити зв'язок типу «один-до-одного». Коли в Microsoft Access на схемі даних відображають зв’язок «один-до-одного», первинний ключ потрібно перетягнути на зовнішній, а не навпаки, оскільки СКБД вважатиме зв'язаною ту таблицю, на яку перетягують поле, а головною — ту, з якої тягнуть. Так, вам потрібно перетягнути поле паспорт таблиці Учителі на поле класний керівник таблиці Класи.

Якщо встановити прапорець Обеспечение целостности данных, то ви побачите біля кінців зв'язку символи «1» і Microsoft Access підтримуватиме обмеження цілісності, тобто не дозволятиме вводити в поле класний керівник таблиці Класи значення, які не є номерами паспортів учителів, представлених у таблиці Учителі. Загалом схема даних набуде такого вигляду, як на рис. Схема бази даних Школа 1 1 1 1

Завдання 5.4 Промоделюйте в базі даних ШКОЛА зв’язок «учитель є класним керівником», створивши у таблиці Класи зовнішній ключ класний керівник та зробивши його індексованим полем без повторень. Уведіть такі дані: Сошко Катерина Миколаївна — класний керівник 10А класу; Петрова Ніна Володимирівна — класний керівник 11А класу; Корбут Василь Петрович – класний керівник 11Б класу. Зобразіть зазначений зв'язок у вікні Схема данных та забезпечте підтримку цілісності даних.

Реалізація концепцій поглибленого семантичного моделювання У розділі 3 ми розглянули такі концепції, як обов'язковість зв'язків, слабкі сутності, зв'язки «є», зв'язки між кількома сутностями та зв'язки сутностей самих із собою. Для їх реалізації у СКБД не потрібно ніяких додаткових засобів, крім тих, які ми вже вивчили, однак спосіб їх застосування має певні особливості.

Обов'язковість зв'язків Зв'язок називається обов'язковим з боку певної сутності, якщо всі об'єкти цієї сутності повинні брати участь у зв'язку. Наприклад, учень повинен вчитися у деякому класі, а клас повинен мати класного керівники (див. рис.) Задамося питанням: коли запис не бере участі у зв'язку, яким буде значення зовнішнього ключа в цьому записі? Очевидно, що воно має бути порожнім. Отже, щоб забезпечити обов'язковість участі записів певної таблиці у зв'язку, слід гарантувати, що її зовнішній ключ не міститиме Null-значень. Для цього параметру Обязательное поле зовнішнього ключа слід надати значення Да (вікно параметрів показано на рис. ). Визначення параметрів зовнішнього ключа для зв'язку “один-до-одного”

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

Завдання 5.5 У базі даних школи забезпечте обов'язковість зв'язку «учень вчиться у класі» з боку таблиці Учні та зв'язків «вчитель є класним керівником» і «школа містить клас» з боку таблиці Класи.

Слабкі сутності Слабкою називається сутність, частина ключа якої складається з атрибутів іншої сутності. Ці атрибути повторюватимуться в обох сутностях і, як неважко помітити, становитимуть зовнішній ключ підтримувального зв'язку у слабкій сутності. Слабка сутність має таку властивість, що частина її ключа є зовнішнім ключем. Так, на рис. а зображено слабку сутність Класи та підтримувальний зв'язок її з сутністю Школи, а на рис. б - реалізація цієї конструкції в схемі даних. Ключ слабкої сутності - це пара атрибутів назва (класу) та назва школи, а зовнішній ключ — атрибут назва школи. Слабкі сутності: а — на моделі «сутність-зв'язок»; б — на схемі даних містить 1 а 1 б

Завдання 5.6 У базі даних школи створіть такий зв'язок між таблицями Класи та Школи, як показано на рис. Для кожного класу вкажіть, що він належить одній з тих шкіл, записи яких ви створювали у завданні 4.5. Крім того створіть другий 10А клас, який має належати іншій школі, ніж уже створений 10А.

Зв'язок «є» Зв'язок «є» створюють між сутністю-загальним типом і сутністю-різновидом. Наприклад, директор — це різновид учителя, а учитель — більш загальний, ніж директор, тип педагогічного працівника. Цей зв'язок завжди має множинність «один-до-одного» і обов'язковий з боку сутності-різновиду. Директор є 1 1

Зв'язок «є» Основна перевага використання зв'язків «є» полягає в тому, що сутність-різновид автоматично «успадковує» всі атрибути сутності-загального типу і їх не потрібно вказувати в сутності-різновиді. У таблиці, що представляє сутність-різновид, достатньо створити лише ключ, який повторюватиме ключ таблиці, що представляє сутність-загальний тип (рис .). Наприклад, учитель Михайлюк Дмитро Семенович є директором. У таблиці Директори ми записуємо тільки номер його паспорта, а в таблиці Учителі — повну інформацію. Фактично за допомогою таблиці Директори ми лише позначаємо деяких учителів: «він є директором».

Зв'язок «є» Для реалізації зв'язку « один-до-одного» типу «є» потрібно вважати первинний ключ таблиці різновиду зовнішнім ключем. А отже, моделюючи цей зв'язок в MS Access, на схемі даних слід перетягнути ключ таблиці-загального типу (наприклад, таблиці Учителі) на ключ таблиці-різновиду (наприклад, таблиці Директори). На схемі даних зв'язок «є» виглядатиме, як показано на рис. 1 1

Завдання 5.7 У базі даних школи створіть зв'язок між таблицями Директори та Учителі, а також Директори і Школи (рис. 3.11. підручника). Вкажіть, що Михайлюк Дмитро Семенович є директором Сомівської гімназії, а Томчишин Віктор Георгійович — директором ЗОШ №77.

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

Завдання 5.8 У базі даних школи створіть тернарний зв'язок між таблицями Учителі, Предмети та Класи згідно з рис. Уведіть інформацію про те, що кожен учитель викладає той предмет, з якого він має спеціальність, у класах, зазначених у завданні 5.3. Крім того, вкажіть, що К.М. Сошко викладає в 11А класі хімію.

Зв'язок сутності самої з собою Є кілька способів моделювання зв'язку сутності самої з собою у СКБД, більш чи менш вдалих з огляду на те, скільки обмежень цілісності вони дозволяють підтримувати. У розділі 3 ми побудували зв'язок «шлюб», який зображено на рис. З ним пов'язані такі обмеження цілісності, як множинність “один-до-одного” та різна стать учителів, що беруть участь у зв'язку. Реалізація концепції поглибленого семантичного моделювання

Найпростіший спосіб реалізації обговорюваного зв'язку - ще раз додати таблицю учителі до схеми даних (її другий екземпляр буде автоматично названо Учителі_1) та зв'язати два екземпляри цієї таблиц зв'язком «один-до-одного». У таблиці Учителі можна створити зовнішній ключ, назвемо його подружжя, зробити його індексованим полем без повторень та зв'язати з первинним з первинним ключем іншого екземпляра цієї ж таблиці (рис. 5.15, ст. 88). Учителі_1 — це не нова таблиця, а просто назва другого подання таблиці Учителі на схемі даних. Щоб показати, скажімо, що Петрова Ніна Володимирівна є дружиною Корбута Василя Петровича, слід у поле подружжя запису Н В. Петрової ввести номер паспорта В.П. Корбута, а поле подружжя В.П. Корбута — номер паспорта Н.В. Петрової Реалізація концепції поглибленого семантичного моделювання

Розглянутий спосіб моделювання зв'язку «шлюб» не гарантує, що стать чоловіка і жінки буде різною. Щоб забезпечити дотримання цього обмеження цілісності, можна створити дві таблиці: учителі-жінки та учителі-чоловіки, з'єднати їх одне з одним та з таблицею учителів (рис. ). Зв'язки між таблицями учителі-жінки і Учителі, а також Учителі-чоловіки і Учителі будуть зв'язками «є»: учитель-жінка є учителем, так само як і учитель-чоловік. Зауважте, що поле стать за такої реалізації буде зайвим, адже стать учителя визначатиметься тим, у якій таблиці вказано його паспорт: чоловіків чи жінок. Реалізація концепції поглибленого семантичного моделювання

Висновки Зовнішній ключ — це поле або набір полів, значення яких повинні належати множині значень первинного ключа деякої іншої таблиці. Кажуть, що зовнішній ключ посилається на таблицю, значення ключа якої він містить. Зовнішні ключі використовують для моделювання зв'язків між таблицями та окремими об'єктами. Якщо певні дві таблиці з'єднані зв'язком, то та, яка містить зовнішній ключ, називається зв'язаною, а інша — головною. Щоб реалізувати зв'язок «один-до-багатьох» (кожному об'єкту А може відповідати багато об'єктів В, але кожному об'єкту В — лише один об'єкт А), потрібно в таблиці В створити зовнішній ключ, що посилатиметься на ьаблицю А. Щоб змоделювати між таблицями А і В зв'язок «багато-до-багатьох», потрібно створити додаткову таблицю С, а вній — два зовнішніх ключі, , що посилатимуться на таблиці А і В. Інакше кажучи до таблиці С слід приєднати таблиці А і В зв'язками «один-до-багатьох» Щоб змоделювати між таблицями А і В зв'язок «один-до-одного», потрібно в одній з таблиць створити зовнішній ключ, що посилатиметься на іншу таблицю. Цей зовнішній ключ має також бути первинним ключем або індексованим полем, у якому повторення значень не допускається.

Завдання для самостійного виконання У базах даних, створених вами у завданні для самостійного виконання з розділу 4, реалізуйте зв'язки між таблицями відповідно до моделей «сутність-зв'язок», спроектованих у розділах 2 і 3. Уведіть дані про зв'язки між кількома об'єктами в кожній БД.