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

4.3.1. Загальна характеристика

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

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

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

4.3.2. Цілісність суті і посилань

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

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

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

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

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

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

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

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