12 правил Кодда

12 правил Кодда — набір 13 правил (пронумерованих від нуля до дванадцяти) запропонованих Едгаром Коддом, піонером реляційної моделі для баз даних, спроектовані для визначення того чи є СКБД реляційною. Іноді їх жартома називають «Дванадцять наказів Кодда».

Кодд створив ці правила як частину своєї кампанії запобігання розмиванню його бачення реляційності оскільки продавці систем керування базами даних на початку 1980х просто видавали свої старі продукти за реляційні розробки. Насправді, правила настільки суворі, що всі популярні так звані «реляційні» СКБД не відповідають багатьом критеріям. Особливо складні 6, 9, 10, 11 і 12 правила.

0. Фундаментальне правило (Foundation Rule)

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

1. Інформаційне правило (Information Rule)

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

2. Правило гарантованого доступу (Guaranteed Access Rule)

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

3. Систематична обробка Null-значень (Systematic Treatment of Null Values)

Невідомі значення NULL, відмінні від будь-якого відомого значення, мають підтримуватись для всіх типів даних при виконанні будь-яких операцій. Наприклад, для числових даних невідомі значення не повинні розглядатись як нулі, а для символьних даних — як порожні рядки.

4. Правило доступу до системного каталогу на основі реляційної моделі (Dynamic On-line Catalog Based on the Relational Model)

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

5. Правило повноти підмови маніпулювання даними (Comprehensive Data Sublanguage Rule)

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

а) має лінійний синтаксис,

б) може використовуватись інтерактивно і в прикладних програмах,

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

6. Правило модифікації розрізів (View Updating Rule)

Кожне подання має підтримувати усі операції маніпулювання даними, які підтримують реляційні таблиці: операції вибірки, вставки, модифікації і видалення даних.

7. Правило високорівневих операцій модифікації даних (High-level Insert, Update, and Delete)

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

8. Правило фізичної незалежності даних (Physical Data Independence)

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

9. Правило логічної незалежності даних (Logical Data Independence)

Представлення даних в додатку не повинно залежати від структури реляційних таблиць. Якщо в процесі нормалізації одна реляційна таблиця розділяється на дві, подання має забезпечити об'єднання цих даних, щоб зміна структури реляційних таблиць не позначалась на роботі додатків.

10. Правило незалежності контролю цілісності (Integrity Independence)

Вся інформація, необхідна для підтримки цілісності, має бути у словнику даних. Мова для роботи з даними має виконувати перевірку вхідних даних і автоматично підтримувати цілісність даних.

11. Правило незалежності від розміщення (Distribution Independence)

База даних може бути розподіленою, може перебувати на кількох комп'ютерах, і це не повинно впливати на додатки, як і перенесення бази даних на інший комп'ютер.

12. Правило узгодженості мовних рівнів (The Nonsubversion Rule)

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