Коли субд можна вважати реляційною

Існує декілька сотень СУБД для мейнфреймів і персональних комп’ютерів. Кожний розробник СУБД заявляє, що розроблена ним СУБД є реляційною. На превеликий жаль багато з них не є реляційними. Стурбований тим, що потенційні можливості реляційної моделі спотворюються, Кодд (Codd, 1985) запропонував 13 правил визначення реляційних систем.

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

1. Фундаментальні правила.

2. Структурні правила.

3. Правила цілісності.

4. Правила управління даними.

5. Правила незалежності від даних.

Фундаментальні правила (правила 0 і 12)

Правило 0. Люба система, яка рекламується або представляється як реляційна СУБД повинна управляти базами даних виключно засобами її реляційних функцій.

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

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

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

Структурні правила (правила 1 і 6)

Правило 1 – представлення інформації. Вся інформація в реляційній базі даних представляються в явному виді на логічному рівні і тільки одним способом – у вигляді значень в таблицях.

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

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

Правила цілісності (правила 3 і 10)

Правило 3 – систематична обробка невизначених значень (NULL). Невизначене значення, яке задається з допомогоюNULL, підтримується для систематичного представлення відсутньої або неприпустимої інформації.

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

Правила маніпулювання даними (правила 2,4,5 і 7)

Ідеальна РСУБД повинна підтримувати 18 функцій управління даними. Вони визначають повноту мови запитів (тут термін “запит” включає і операцію вставки, поновлення і видалення).

Правило 2 – гарантований доступ.Для всіх і кожного елементу даних реляційної бази даних повинен бути гарантований доступ на основі комбінації імені таблиці, значення первинного ключа і значення імені стовпчика.

Правило 4 – динамічний інтерактивний каталог, побудований за правилами реляційної моделі. Опис бази даних повинен представлятись на логічному рівні таким же чином як і звичайні дані. Це дозволить користувачам використовувати для звертання до цього опису ту ж реляційну мову, що для даних.

Це правило вказує на те, що повинен існувати лише одна мова для маніпулювання як даними так і метаданими.

Правило 5 – вичерпна мова даних. Реляційна система може підтримувати декілька мов і різні режими роботи з терміналами. Але повинна існувати по меншій мірі одна мова, оператори котрої реалізовували такі конструкції:

1. визначення даних;

2. визначення представлень;

3. команди маніпулювання даними (доступні як в інтерактивному режимі так і з програм);

4. обмеження цілісності;

5. авторизація користувачів;

6. організація транзакцій (запуск, фіксація, відкат).

Слід зауважити, що новий стандарт ISO для мови SQL забезпечує виконання всіх цих функцій.

Правило 7 – високорівневі операції вставки, поновлення і видалення. Здатність обробляти базові або похідні відношення (представлення) як єдиний операнд повинна відноситись не тільки до процедури виборки даних а і до операцій вставки, поновлення і видалення.

Правила незалежності від даних (правила 8,9 і 11)

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

Правило 8 – фізична незалежність від даних. Прикладні програми і засоби роботи з терміналами повинні залишатись логічно незмінними при внесенні любих змін в способи зберігання даних або методи доступу до них.

Правило 9 – логічна незалежність від даних. Прикладні програми і засоби роботи з терміналами повинні залишатись логічно незмінними при внесенні в базові таблиці любих змін, які теоретично не повинні зачіпати прикладне програмне забезпечення.

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