Реляційні моделі бази даних
Введення
Основні ідеї сучасної інформаційної технології
базуються на концепції баз даних (БД). Відповідно до даної концепції основою
інформаційної технології є дані, організовані в БД, адекватно
відображають реалії дійсності в тій або іншій предметній області і
забезпечують користувача актуальною інформацією у відповідній предметній
області. У широкому сенсі слова база даних - це сукупність описів
об'єктів реального світу і зв'язків між ними, актуальних для конкретної
прикладної області.
Як сутності, атрибути та зв'язку відображаються на структури
даних - визначається моделлю даних.
Традиційно всі СУБД класифікуються в залежності від
моделі даних, яка лежить в їх основі. Прийнято виділяти ієрархічну,
мережеву та реляційну моделі даних. Іноді до них додають модель даних на
основі інвертований списків. Відповідно говорять про ієрархічних,
мережевих, реляційних СУБД або про СУБД на базі інвертований списків.
За поширеністю і популярності реляційні СУБД
сьогодні - поза конкуренцією. Вони стали фактичним промисловим стандартом, і
тому вітчизняному користувачеві доведеться зіткнутися в своїй практиці
саме з реляційної СУБД.
Основи реляційної моделі даних були вперше викладені
у статті Е. Кодда в 1970 р. Ця робота послужила стимулом для великого
кількості статей і книг, в яких реляційна модель отримала подальший
розвиток. Найбільш поширена трактування реляційної моделі даних
належить К. Дейта [1]
. Згідно Дейта, реляційна модель
складається з трьох частин:
Структурною частини.
Цілісної частини.
маніпуляційної частини.
Структурна частина описує, які об'єкти
розглядаються реляційної моделлю. Постулюється, що єдиною структурою
даних, що використовується в реляційної моделі, є нормалізовані n-арние
відносини.
Цілісна частина описує обмеження спеціального
виду, які повинні виконуватися для будь-яких відносин у будь-яких реляційних базах
даних. Це цілісність сутностей та цілісність зовнішніх ключів.
Маніпуляційна частина описує два еквівалентних
способу маніпулювання реляційними даними - реляційну алгебру і
реляційне числення.
Мета даної роботи розглянути структурну і цілісну
частина реляційної моделі бази даних.
1. Структурна частина
реляційної моделі
1.1 Типи даних
Будь-які дані, які використовуються в програмуванні, мають
свої типи даних.
Реляційна модель вимагає, щоб типи використовуваних
даних були простими.
Для уточнення цього твердження розглянемо, які
взагалі типи даних зазвичай розглядаються в програмуванні. Як правило, типи
даних поділяються на три групи:
Прості типи даних.
Структуровані типи даних.
Нормативний типи даних.
Прості, або атомарні, типи даних
не володіють внутрішньою структурою. Дані такого типу називають скалярами. До
простим типів даних відносяться наступні типи: Логічний, Рядковий, Чисельний [2]
.
Різні мови програмування можуть розширювати і
уточнювати цей список, додаючи такі типи як:
Цілий.
Речовий.
Дата.
Час.
Грошовий.
Перечіслімий.
Інтервальний.
І так далі ...
Звичайно, поняття атомарності досить відносно.
Так, рядковий тип даних можна розглядати як одновимірний масив символів, а
цілий тип даних - як набір бітів. Важливо лише те, що при переході на такий
низький рівень втрачається семантика (зміст) даних. Якщо рядок, що виражає,
наприклад, прізвище співробітника, розкласти в масив символів, то при цьому втрачається
сенс такого рядка як єдиного цілого.
Структуровані типи даних призначені для
завдання складних структур даних. Структуровані типи даних конструюються
зі складових елементів, які називаються компонентами, які, у свою чергу,
можуть володіти структурою. Як структурованих типів даних можна
привести такі типи даних:
Масиви
Записи (Структури)
З математичної точки зору масив представляє
собою функцію з кінцевою областю визначення. Наприклад, розглянемо кінцеве
безліч натуральних чисел
зване безліччю індексів. Відображення
з безлічі 
в безліч
дійсних чисел 
задає
одновимірний речовинний масив. Значення цієї функції для деякого значення
індексу 
називається
елементом масиву, відповідним . Аналогічно
можна задавати багатовимірні масиви.
Запис (або структура) являє собою кортеж із
деякого декартового твори множин. Дійсно, запис
являє собою іменований упорядкований набір елементів 
, кожен з
яких належить типу 
. Таким
чином, запис 
є елемент
безлічі 
. Оголошуючи
нові типи записів на основі вже наявних типів, користувач може
конструювати як завгодно складні типи даних [3]
.
Загальним для структурованих типів даних є те,
що вони мають внутрішню структуру, яка використовується на тому ж рівні абстракції,
що й самі типи даних.
При роботі з масивами або записами можна маніпулювати
масивом або записом і як з єдиним цілим (створювати, видаляти, копіювати цілі
масиви або запису), так і поелементно. Для структурованих типів даних є
спеціальні функції - конструктори типів, що дозволяють створювати масиви або
запису з елементів більш простих типів.
Працюючи ж з простими типами даних, наприклад з
числовими, ми маніпулюємо ними як неподільними цілими об'єктами. Щоб
"побачити", що числовий тип даних насправді складний (є
набором бітів), потрібно перейти на більш низький рівень абстракції. На рівні
програмного коду це буде виглядати як асемблерні вставки в код на мові
високого рівня або використання спеціальних побітне операцій.
Нормативний тип даних (покажчики) призначений для
забезпечення можливості вказівки на інші дані. Покажчики характерні для
мов процедурного типу, в яких є поняття області пам'яті для зберігання
даних. Нормативний тип даних призначений для обробки складних змінюються
структур, наприклад дерев, графів, рекурсивних структур.
Для реляційної моделі даних тип використовуваних даних
не має значення. Вимога, щоб тип даних був простим, потрібно розуміти так, що в
реляційних операціях не повинна враховуватися внутрішня структура даних.
Звичайно, повинні бути описані дії, які можна виробляти з даними як
з єдиним цілим, наприклад, дані числового типу можна складати, для рядків
можлива операція конкатенації і т.д.
З цієї точки зору, якщо розглядати масив,
наприклад, як єдине ціле і не використовувати поелементний операцій, то масив
можна вважати простим типом даних. Більш того, можна створити свій, як
завгодно складних тип даних, описати можливі дії з цим типом даних, і,
якщо в операціях не потрібно знання внутрішньої структури даних, то такий тип
даних також буде простим з точки зору реляційної теорії. Наприклад, можна
створити новий тип - комплексні числа як запис виду 
, де 
. Можна
описати функції додавання, множення, віднімання і ділення, і всі дії з
компонентами 
і 
виконувати
тільки всередині цих операцій. Тоді, якщо в діях з цим типом використовувати
тільки описані операції, то внутрішня структура не грає ролі, і тип даних
ззовні виглядає як атомарний.
Саме так у деяких пост-реляційних СУБД
реалізована робота з як завгодно складними типами даних, що створюються
користувачами.
1.2 Домени
У реляційної моделі даних з поняттям тип даних
тісно пов'язане поняття домену, яке можна вважати уточненням типу даних.
Домен - це семантичне поняття. Домен можна
розглядати як підмножина значень деякого типу даних мають
певний сенс. Домен характеризується такими властивостями:
Домен має унікальне ім'я (в межах бази даних).
Домен визначений на деякому простому типі даних або
на іншому домені.
Домен може мати деякий логічне умова,
дозволяє описати підмножина даних, допустимих для даного домену.
Домен несе певну смислове навантаження.
Наприклад, домен 
, що має
сенс "вік співробітника" можна описати як наступне підмножина
безлічі натуральних чисел:
Якщо тип даних можна вважати безліччю всіх
можливих значень даного типу, то домен нагадує підмножина в цьому
множині.
Відмінність домену від поняття підмножини полягає саме
в тому, що домен відображає семантику, визначену предметною областю. Може
бути кілька доменів, що збігаються як підмножини, але несуть різний
сенс. Наприклад, домени "Вага деталі" і "Наявне
кількість "можна однаково описати як множину невід'ємних цілих
чисел, але зміст цих доменів буде різним, і це будуть різні домени [4]
.
Основне значення доменів полягає в тому, що домени
обмежують порівняння. Некоректно, з логічної точки зору, порівнювати
значення з різних доменів, навіть якщо вони мають однаковий тип. У цьому
проявляється смислове обмеження доменів. Синтаксично правильний запит
"видати список всіх деталей, у яких вага деталі більше наявної кількості"
не відповідає змісту понять "кількість" і "вагу".
Поняття домену допомагає правильно моделювати
предметну область. При роботі з реальною системою в принципі можлива ситуація
коли потрібно відповісти на запит, наведений вище. Система дасть відповідь, але,
ймовірно, він буде безглуздим.
Не всі домени мають логічним умовою,
обмежує можливі значення домену. У такому випадку безліч можливих
значень домену збігається з безліччю можливих значень типу даних.
1.3 Відносини, атрибути,
кортежі відносини
Фундаментальним поняттям
реляційної моделі даних є поняття відносини. У визначенні поняття
відносини будемо слідувати книзі К. Дейта.
Атрибут відносини є пара виду <Імя_атрібута:
Ім'я_домену>.
Імена атрибутів повинні бути унікальні в межах
відносини. Часто імена атрибутів відносини збігаються з іменами відповідних
доменів.
Відношення 
, визначене
на безлічі доменів 
(не
обов'язково різних), містить дві частини: заголовок і тіло.
Заголовок відносини містить фіксовану кількість
атрибутів відносини:
Тіло відносини містить безліч кортежів відносини.
Кожен кортеж відносини являє собою безліч пар виду <Імя_атрібута
: Значеніе_атрібута>:
таких що значення 
атрибуту 
Відношення звичайно записується у вигляді:
,
або коротше
,
або просто
.
Число атрибутів у відношенні називають ступенем (або
-арность) відносини. Потужність множини кортежів відносини називають потужністю
відносини.
Заголовок відносини описує декартовій твір
доменів, на якій задане відношення. Заголовок статичний, він не змінюється під
час роботи з базою даних. Якщо стосовно змінені, додані або видалені
атрибути, то в результаті отримаємо вже інше ставлення (нехай навіть з колишнім
ім'ям).
Тіло відносини являє собою набір кортежів, тобто
підмножина декартового твори доменів. Таким чином, тіло відносини
власне і є відношенням в математичному сенсі слова. Тіло відносини
може змінюватися під час роботи з базою даних - кортежі можуть змінюватися,
додаватися і віддалятися.
Розглянемо відношення "Співробітники" заданий
на доменах "Номер_сотрудніка", "Прізвище",
"Зарплата", "Номер_отдела". Оскільки всі домени різні, то
імена атрибутів відносини зручно назвати так само, як і відповідні домени. Заголовок
відносини має вигляд:
Співробітники (Номер_сотрудніка, Прізвище, Зарплата,
Номер_отдела)
Нехай в даний момент відношення містить три кортежу:
(1, Іванов, 1000, 1)
(2, Петров, 2000, 2)
(3, Сидоров, 3000, 1)
таке ставлення природним чином представляється у
вигляді таблиці [5]
:
Таблиця 1 Ставлення "Співробітники"
Номер_сотрудніка
Прізвище
Зарплата
Номер_отдела
1
Іванов
1000
1
2
Петров
2000
2
3
Сидоров
3000
1
реляційної базою даних називається набір відносин.
Схемою реляційної бази даних називається набір
заголовків відносин, що входять до бази даних.
Хоча будь-яке відношення можна зобразити у вигляді таблиці,
потрібно чітко розуміти, що відносини не є таблицями. Це близькі, але не
збігаються поняття. Відмінності між відносинами і таблицями будуть розглянуті
нижче.
Терміни, якими оперує реляційна модель даних,
мають відповідні "табличні" синоніми:
Реляційний термін
Відповідний
"табличний" термін
База даних
Набір таблиць
Схема бази даних
Набір заголовків таблиць
Відношення
Таблиця
Заголовок відносини
Заголовок таблиці
Тіло відносини
Тіло таблиці
Атрибут відносини
Назва стовпця
таблиці
Кортеж відносини
Рядок таблиці
Ступінь (-арность)
відносини
Кількість стовпців таблиці
Потужність відносини
Кількість рядків таблиці
Домени та типи даних
Типи дані в комірках
таблиці
Властивості відносин безпосередньо
випливають з наведеного вище визначення ставлення. У ці властивості в основному
і полягають відмінності між відносинами і таблицями.
Відносно немає однакових кортежів. Дійсно,
тіло відносини є безліч кортежів і, як будь-яке безліч, не може містити
нерозрізнені елементи. Таблиці на відміну від відносин можуть містити
однакові рядки.
кортеж не впорядковані (зверху вниз). Дійсно,
незважаючи на те, що ми зобразили ставлення "Співробітники" у вигляді
таблиці, не можна сказати, що співробітник Іванов "передує"
співробітнику Петрову. Причина та ж - тіло відносини є безліч, а безліч
не впорядкована. Це друга причина, через яку не можна ототожнити відносини і
таблиці - рядки в таблиці впорядковані. Одна і та ж відношення може бути зображено
різними таблицями, в яких рядки йдуть у різному порядку.
Атрибути не впорядковані (зліва направо). Оскільки к?? ждий
атрибут має унікальне ім'я в межах відносини, то порядок атрибутів не
має значення. Ця властивість кілька відрізняє ставлення від математичного
визначення ставлення. Це також третя причина, через яку не можна ототожнити
відносини і таблиці - стовпці в таблиці впорядковані. Одна і та ж відношення
може бути зображено різними таблицями, в яких стовпці йдуть у різному порядку.
Всі значення атрибутів атомарний. Це випливає з того,
що лежать в їх основі атрибути мають атомарні значення. Це четверте
відміну відносин від таблиць - в комірки таблиць можна помістити будь-що --
масиви, структури, і навіть інші таблиці [6]
.
З властивостей відносини слід, що не кожна таблиця
може задавати ставлення. Для того, щоб деяка таблиця задавала ставлення,
необхідно, щоб таблиця мала просту структуру (містила б тільки рядки і
стовпці, причому, у кожному рядку було б однакову кількість полів), у
таблиці не повинно бути однакових рядків, будь-який стовпець таблиці повинен містити
дані тільки одного типу, всі використовувані типи даних повинні бути простими.
Кожне ставлення можна вважати класом еквівалентності
таблиць, для яких виконуються наступні умови:
Таблиці мають однакову кількість стовпців.
Таблиці містять стовпці з однаковими найменуваннями.
Стовпці з однаковими найменуваннями містять дані
з одних і тих самих доменів.
Таблиці мають однакові рядки з урахуванням того, що
порядок стовпців може відрізнятися.
Всі такі таблиці є різні зображення одного і
того ж відносини.
Найважче дати визначення речей, які всім
зрозумілі. Якщо давати не строге, описову визначення, то завжди залишається
можливість неправильного його трактування. Якщо дати суворе формальне
визначення, то воно, як правило, або тривіально, або занадто громіздким. Саме
така ситуація з визначенням відносини у Першій Нормальною Форме (1НФ). Дати визначення
1НФ складно з огляду на його тривіальності. Тому, наведемо кілька пояснень.
1. Кажуть, що ставлення знаходиться в
1НФ, якщо воно задовольняє визначенню 2.
Це, власне, тавтологія, адже з визначення 2
випливає, що інших стосунків не буває. Дійсно, визначення 2
описує, що є відношенням, а що - ні, отже, відносин у
непервой нормальній формі просто немає.
2. Кажуть, що ставлення знаходиться в
1НФ, якщо його атрибути містять тільки скалярні (атомарні) значення.
Знову ж таки, друге визначення спирається на поняття
домену, а домени визначені на простих типи даних.
Не першу нормальну форму можна отримати, якщо
допустити, що атрибути відносини можуть бути визначені на складних типах даних
- Масивах, структурах, або навіть на інших відносинах. Легко собі уявити
таблицю, у якої в деяких осередках містяться масиви, в інших осередках --
визначені користувачами складні структури, а в третьому осередках - цілі
реляційні таблиці, які в свою чергу можуть містити такі ж складні
об'єкти. Саме такі можливості надаються деякими сучасними
пост-реляційними і об'єктними СУБД.
Вимога, що відносини повинні містити тільки
дані простих типів, пояснює, чому відносини іноді називають плоскими
таблицями (plain table). Дійсно, таблиці, які визначають відносини двовимірних.
Одне вимірювання задається списком стовпчиків, другий вимір задається списком
рядків. Пара координат (Номер рядка, Номер стовпця) однозначно ідентифікує
комірку таблиці і що міститься в ній значення. Якщо ж припустити, що в комірці
таблиці можуть міститися дані складних типів (масиви, структури, інші
таблиці), то така таблиця буде вже не плоскою. Наприклад, якщо в комірці
таблиці міститься масив, то для звернення до елемента масиву потрібно знати три
параметра (Номер рядка, Номер стовпця, номер елемента в масиві). Таким
чином з'являється третя пояснення Першої Нормальною Форми: Ставлення знаходиться в
1НФ, якщо воно є плоскою таблицею [7]
.
У цьому розділі була розглянута тільки класична
реляційна теорія, в якій усі відносини мають тільки атомарні атрибути та
свідомо перебувають у 1НФ.
2. Цілісність
реляційних даних
У другій частині реляційної моделі даних визначаються
два обмеження, які повинні виконуватися в будь-який реляційної бази даних.
Це:
Цілісність сутностей.
Цілісність зовнішніх ключів.
Перш, ніж описувати цілісність сутностей,
необхідно описати використання null-значений в реляційних базах даних.
2.1 Null-значення
Основне призначення баз даних полягає в тому, щоб
зберігати і надавати інформацію про реальний світі. Для представлення цієї
інформації в базі даних використовуються звичні для програмістів типи даних --
рядкові, чисельні, логічні і т.п. Однак у реальному світі часто
трапляється ситуація, коли дані невідомі або не повні. Наприклад, місце
проживання або дата народження людини можуть бути невідомі (база даних
розшукуваних злочинців). Якщо замість невідомої адреси доречно було б
вводити порожній рядок, то що вводити замість невідомої дати? Відповідь - порожню
дату - не цілком задовільний, тому що найпростіший запит "видати список
людей у порядку зростання дат народження "дасть свідомо неправильних
відповідь.
Для того щоб обійти проблему неповних або
невідомих даних, в базах даних можуть використовуватися типи даних, поповнені
так званим null-значенням. Null-значення - це, власне, не значення, а
якийсь маркер, який показує, що значення невідомо.
Таким чином, у ситуації, коли можлива поява
невідомих або неповних даних, розробник має на вибір два варіанти.
Перший варіант полягає в тому, щоб обмежитися
використанням звичайних типів даних і не використовувати null-значення, а замість
невідомих даних вводити або нульові значення, або значення спеціального
виду - наприклад, домовитися, що рядок "Адреса невідома" і є
ті дані, які потрібно вводити замість невідомої адреси. У будь-якому випадку на
користувача (або на розробника) лягає відповідальність на правильну
трактування таких даних. Зокрема, може знадобитися написання спеціального
програмного коду, що в потрібних випадках "виловлював" б такі
дані. Проблеми, що виникають при цьому очевидні - не всі дані стають
рівноправні, потрібен додатковий програмний код,
"відслідковує" цю нерівноправність, в результаті чого ускладнюється
розробка та супровід програм.
Другий варіант полягає у використанні null-значений
замість невідомих даних. За очікуваною природністю такого підходу
ховаються менш очевидні і більш глибокі проблеми. Найбільш впадає в очі
проблемою є необхідність використання тризначної логіки при
оперування з даними, які можуть містити null-значення. У цьому випадку
при неакуратному формулюванні запитів, навіть самі природні запити можуть
давати неправильні відповіді. Є більш фундаментальні проблеми, пов'язані з
теоретичним обгрунтуванням коректності введення null-значення, наприклад,
незрозуміло взагалі, чи входять null-значення у домени чи ні.
Питання про проблеми використання null-значений в
теорії реляційних баз даних остаточно не вирішене. Основоположник
реляційного підходу Коддом вважав null-значення невід'ємною частиною реляційної
моделі, хоча К. Дейт виступає проти null-значень [8]
.
2.2 Потенційні ключі
і цілісність сутностей
По визначенню, тіло відношення є безліч
кортежів, тому відношення не можуть містити однакові кортежі. Це означає,
що кожен кортеж повинний мати властивість унікальності. Насправді,
властивістю унікальності в межах відношення можуть володіти окремі атрибути
кортежів або групи атрибутів. Такі унікальні атрибути зручно використовувати
для ідентифікації кортежів.
Нехай дано відношення . Підмножина
атрибутів 
відносини 
будемо називати
потенційним ключем, якщо володіє
наступними властивостями:
Властивістю унікальності - у відношенні не може бути
двох різних кортежів, з однаковим значенням .
Властивістю неізбиточності - ніяке підмножина в не має
властивістю унікальності.
Будь-яке відношення має принаймні один
потенційний ключ. Дійсно, якщо ніякої атрибут або група атрибутів не
є потенційним ключем, то, в силу унікальності кортежів, всі атрибути
разом утворюють потенційний ключ. Потенційний ключ, що складається з одного
атрибуту, називається простим. Потенційний ключ, що складається з декількох
атрибутів, називається складовим. Відношення може мати кілька потенційних
ключів. Традиційно, один з потенційних ключів оголошується первинним, а решта
- Альтернативними. Відмінності між первинним і альтернативними ключами можуть
бути важливі в конкретній реалізації реляційної СУБД, але з точки зору
реляційної моделі даних, немає підстав виділяти таким чином один з
потенційних ключів. Поняття потенційного ключа є семантичним
поняттям і відображає певний сенс (трактування) понять з конкретної
предметної області. Для того щоб проілюструвати цей факт, розглянемо
відношення "Співробітники" (Додаток 1).
При першому погляді на таблицю, що зображає це
ставлення, може здатися, що в таблиці є три потенційних ключа - в
кожній колонці таблиці містяться унікальні дані. Однак серед співробітників
можуть бути однофамільці та співробітники з однаковою зарплатою. Табельний же номер
по суті свій унікальний для кожного співробітника. Які ж міркування привели нас
до розуміння того, що в цьому відношенні тільки один потенційний ключ --
"Табельний номер"? Саме розуміння змісту даних, що містяться в
відношенні.
Спробуємо уявити це відношення в іншому вигляді,
змінивши найменування атрибутів:
A
B
C
1
Іванов
1000
2
Петров
2000
3
Сидоров
3000
Пред'явивши кому-небудь цю таблицю і не повідомимо сенс
найменувань атрибутів. Очевидно, що неможливо судити, не розуміючи змісту
даних, може чи не може в цьому відношенні з'явитися, наприклад, кортеж (1,
Петров, 3000). Якщо б, до речі, такий кортеж з'явився (що, на перший погляд,
цілком можливо, бо не порушується унікальність кортежів), то ми точно змогли
б сказати, що не є альтернативним ключем - ні один з атрибутів по
окремо. Але ми не зможемо сказати, що ж є первинним ключем [9]
.
Потенційні ключі служать засобом ідентифікації
об'єктів предметної області, дані про які зберігаються у відношенні. Об'єкти
предметної області повинні бути помітні.
Потенційні ключі служать єдиним засобом
адресації на рівні кортежів у відношенні. Точно вказати який-небудь кортеж
можна тільки знаючи значення його потенційного ключа.
Оскільки потенційні ключі фактично служать
ідентифікаторами об'єктів предметної області (тобто призначені для розрізнення
об'єктів), то значення цих ідентифікаторів не можуть містити невідомі
значення. Дійсно, якщо б ідентифікатори могли містити null-значення,
то ми не могли б дати відповідь "так" або "ні" на питання,
співпадають чи ні два ідентифікатора.
Це визначає наступне правило цілісності
сутностей:
Атрибути, що входять до складу деякого потенційного
ключа не можуть брати null-значень.
2.3 Зовнішні ключі та їх
цілісність
Різні об'єкти предметної області, інформація про
яких зберігається в базі даних, завжди взаємозв'язані між собою. Наприклад,
накладна на поставку товару містить список товарів з кількістю і цінами,
співробітник підприємства має дітей, числиться в підрозділі і т.д. Терміни
"містить", "має", "числиться" відображають взаємозв'язки
між поняттями "накладна" і "список товарів",
"співробітник" і "діти", "співробітник" і
"підрозділ". Такі взаємозв'язки відображаються в реляційних базах
даних за допомогою зовнішніх ключів, що зв'язують кілька відносин.
Розглянемо приклад з постачальниками і поставками деталей.
Припустимо, що нам потрібно зберігати інформацію про найменування постачальників,
найменування та кількості поставляються ними деталей, причому кожен постачальник
може постачати кілька деталей і кожна деталь може поставлятися декількома
постачальниками. Можна запропонувати зберігати дані в наступному відношення (
Додаток 2).
Потенційним ключем цього відношення може виступати
пара атрибутів ( "Номер постачальника", "Номер деталі") - в
таблиці вони виділені курсивом.
Наведений спосіб зберігання даних має ряд
недоліків.
Що відбудеться, якщо змінилося найменування
постачальника? Оскільки найменування постачальника повторюється в багатьох кортежу
відносини, то це найменування потрібно одночасно змінити у всіх кортежу,
де воно зустрічається, інакше дані стануть суперечливими. Те ж саме з
найменуваннями деталей. Отже, дані зберігаються в нашому ставленні з великою
надмірністю.
Далі, як відобразити факт, що деякий постачальник,
наприклад Петров, тимчасово припинив постачання деталей? Якщо ми видалимо всі
кортежі, у яких зберігається інформація про постачання цього постачальника, то ми
втратимо дані про самому Петрові як потенційного постачальника. Вийти з цього
положення, залишивши у відношенні кортеж типу (2, Петров, NULL, NULL, NULL) ми не
можемо, тому що атрибут "Номер деталі" входить до складу потенційного
ключа і не може містити null-значень. Те ж саме станеться, якщо
деяка деталь тимчасово не поставляється ніяким постачальником. Виходить, що
ми не можемо зберігати інформацію про те, що є певний постачальник, якщо він не
поставляє хоча б одну деталь, і не можемо зберігати інформацію про те, що є
деяка деталь, якщо вона ніким не поставляється.
Подібні проблеми виникають тому, що ми змішали в
одному відношенні різні об'єкти предметної області - і дані про постачальників,
і дані про деталі, і дані про постачання деталей. Кажуть, що це відношення
погано нормалізовано (просто нормалізованому воно є хоча б тому, що
воно є відношення і, отже, автоматично знаходиться в 1НФ).
Про те, як правильно нормалізувати відносини, буде
сказано в наступних розділах, зараз же запропонуємо рознести дані по трьох
відносин - "Постачальники", "Деталі", "Постачання".
Для нас важливо з'ясувати, яким чином дані, що зберігаються в цих відносинах
взаємопов'язані між собою. Цей зв'язок визначається семантикою предметної
області і описується фразами: "Постачальники виконують Постачання",
"Деталі поставляються через Поставки". Ці два взаємозв'язку побічно
визначають новий взаємозв'язок між "Постачальниками" і
"Деталями": "Деталі поставляються Постачальниками".
Ці фрази відображають різні типи взаємозв'язків. Щоб
більш точно відобразити предметну область, можна інакше переформулювати фрази:
"Один Постачальник може виконувати декілька Поставок", "Одна
Деталь може поставлятися кількома Поставками ". Це приклад взаємозв'язку
типу "один-ко-многим". Взаємозв'язок між "Постачальниками" і
"Деталями" можна переформулювати так: "Кілька Деталей може
поставлятися кількома Постачальниками ". Це приклад взаємозв'язку типу
"багато-ко-многим".
У реляційних базах даних основними є
взаємозв'язку типу "один-ко-многим". Взаємозв'язки типу
"багато-ко-многим" реалізуються використанням декількох взаємозв'язків
типу "один-ко-многим". Ставлення, що входить у зв'язок з боку
"один" (наприклад, "Постачальники"), називають батьківським
ставленням. Ставлення, що входить у зв'язок з боку "багато" (наприклад,
"Постачання"), називається дочірньому ставленням.
Механізм реалізації взаємозв'язку
"один-ко-многим" полягає в тому, що в дочірнє ставлення додаються
атрибути, які є посиланнями на кл?? чевие атрибути батьківського відносини. Ці
атрибути і є зовнішніми ключами, що визначають, з якими кортежами
батьківського відносини пов'язані кортежі дочірнього відносини. Такі атрибути ще
називають мігрують з батьківського відносини.
Таким чином, наш приклад з постачальниками і
поставляються деталями повинен виглядати наступним чином:
Таблиця 2 Ставлення "Постачальники"
Номер постачальника
Найменування постачальника
1
Іванов
2
Петров
3
Сидоров
Таблиця 3 Ставлення "Деталі"
Номер деталі
Найменування деталі
1
Болт
2
Гайка
3
Гвинт
Таблиця 4 Відношення "Постачання"
Номер постачальника
Номер деталі
постачається кількість
1
1
100
1
2
200
1
3
300
2
1
150
2
2
250
3
3
1000
Відносно "Постачання" атрибути "Номер
постачальника "і" Номер деталі "є посиланнями на ключові
атрибути відносин "Постачальники" і "Деталі", і,
отже, є зовнішніми ключами. Зауважимо, що дані відносини
вільні від недоліків, описаних вище, коли всі дані пропонувалося зберігати
в одному відношенні. Дійсно, при зміні найменування постачальника або
деталі, ця зміна відбувається тільки в одному місці. Якщо постачальник припинив
постачання всіх деталей, то віддаляються відповідні кортежі відносно
"Постачання", дані ж про самого постачальника залишаються без змін.
Нехай дано відношення . Підмножина
атрибутів 
відносини будемо називати
зовнішнім ключем, якщо:
Існує ставлення 
(
і 
не обов'язково
різні) з потенційним ключем .
Кожне значення стосовно завжди
таке саме, як для деякого
кортежу з , або
є null-значенням.
Відношення називається
батьківським ставленням, ставлення називається
дочірнім ставленням.
Зовнішній ключ, також як і потенційний, може бути
простим і складеним.
Зовнішній ключ повинен бути визначений на тих же доменах,
що і відповідний первинний ключ батьківського відносини.
Зовнішній ключ, як правило, не має властивість
унікальності. Так і повинно бути, тому що в дочірньому відношенні може бути кілька
кортежів, що посилаються на один і той же кортеж батьківського відносини. Це,
власне, і дає тип відношення "один-ко-многим".
Якщо зовнішній ключ все-таки має властивість
унікальності, то зв'язок між відносинами має тип "один-до-одного".
Найчастіше такі відносини об'єднуються в одне відношення, хоча це і не
обов'язково.
Хоча кожне значення зовнішнього ключа обя
