3 Реляційна модель даних

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

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

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

• структурної частини;

• маніпуляціоної частини;

• цілісної частини.

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

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

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

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

Друга вимога називається вимогою цілісності по посиланнях і є трохи більш складною. Очевидно, що при дотриманні нормалізованості відносин складні сутності реального світу представляються в реляційної БД у вигляді кількох кортежів кількох відносин. Наприклад, представимо, що нам потрібно представити в реляційної базі даних сутність ВІДДІЛ з атрибутами НОМЕР_ВІДД (номер відділу), ВІДД_КІЛ (кількість співробітників) і СП_НОМЕР (набір співробітників відділу). Для кожного співробітника потрібно зберігати СП_НОМЕР (номер співробітника), СП_ІМ'Я (ім'я співробітника) і СП_ЗАРП (заробітна плата співробітника). Як ми незабаром побачимо, при правильному проектуванні відповідної БД у ній з'являться двоє відносин: ВІДДІЛИ (НОМЕР_ВІДД, ВІДД_КІЛ) (первинний ключ – НОМЕР_ВІДД) і СПІВРОБІТНИКИ (СП_НОМЕР, СП_ІМ'Я, СП_ЗАРП, СП_ВІДД_НОМ) (первинний ключ - СП_НОМЕР).

Як видно, атрибут СП_ВІДД_НОМ з'являється у відношенні СПІВРОБІТНИКИ не тому, що номер відділу є власною властивістю співробітника, а лише для того, щоб мати можливість відновити при необхідності повну сутність ВІДДІЛ. Значення атрибута СП_ВІДД_НОМ у будь-якому кортежі відносини СПІВРОБІТНИКИ повинні відповідати значенню атрибуту ВІДД_НОМ у деякому кортежі відносини ВІДДІЛИ. Атрибут такого роду називається, як ми вже знаємо, зовнішнім ключем, оскільки його значення однозначно характеризують сутності, представлені кортежами деякого іншого відношення (тобто задають значення їхнього первинного ключа). Говорять, що відношення, у якому визначений зовнішній ключ, посилається на відповідне відношення, у якому такий же атрибут є первинним ключем.

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

Обмеження цілісності сутності і по посиланнях повинні підтримуватися СУБД. Для дотримання цілісності сутності досить гарантувати відсутність у будь-якому відношенні кортежів з тим самим значенням первинного ключа. З цілісністю по посиланнях справи йдуть трохи більш складно.

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

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

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

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