12 Правил Кодда:
Реляційна СКБД повинна бути здатна повністю управляти базою даних через її реляційні можливості.
Інформаційне правило - вся інформація в реляційній БД (включаючи імена таблиць і стовпців) повинна визначатися строго як значення в таблицях.
Гарантований доступ - будь-яке значення в реляційній БД повинне бути гарантированно доступно для використання через комбінацію імені таблиці, значення первинного ключа й імені стовпця
Підтримка порожніх значень (null value) - СКБД повинна вміти працювати з порожніми значеннями (невідомими або невикористаними значеннями), на відміну від значень за замовчуванням і незалежно для будь-яких доменів.
Онлайновий реляційний каталог - опис БД та її змісту повинні бути представлені на логічному рівні як таблиці, до яких можна застосовувати запити, використовуючи мову бази даних.
Вичерпна мова керування даними - принаймні, одна з підтримуваних мов повинна мати чіткий певний синтаксис і бути всеосяжною. Вона повинна підтримувати опис структури даних і маніпулювання ними, правила цілісності, авторизацію й транзакції.
Правило відновлення подань (views) - всі подання, теоретично обновлювані, можуть бути обновлені через систему.
Вставка, відновлення й видалення - СКБД підтримує не тільки запит на відбір даних, але й вставку, відновлення й видалення
Фізична незалежність даних - на програми-додатки й спеціальні програми логічно не впливають зміни фізичних методів доступу до даних і структур сховищ даних.
Логічна незалежність даних - на програми-додатки й спеціальні програми логічно не впливають, у межах розумного, зміни структур таблиць.
Незалежність цілісності - мова БД повинна бути здатна визначати правила цілісності. Вони повинні зберігатися в онлайновому довіднику, і не повинно існувати способу їх обійти.
Незалежність розподілу - на програми-додатки й спеціальні програми логічно не впливає, перший раз використаються дані або повторно.
Непідривність - неможливість обійти правила цілісності, визначені через мову бази даних, використанням мов низького рівня
Кодд запропонував застосування реляційної алгебри в СКРБД, для розчленовування даних у зв'язані набори. Він організував свою систему БД навколо концепції, заснованої на наборах даних.
У реляційній моделі дані розбиваються на набори, які становлять табличну структуру. Ця структура таблиць складається з індивідуальних елементів даних, називаних полями. Одиночний набір або група полів відома як запис.
Модель даних, або концептуальний опис предметної області - самий абстрактний рівень проектування баз даних.
З погляду теорії реляційних БД, основні принципи реляційної моделі на концептуальному рівні можна сформулювати в такий спосіб:
усі дані представляються у вигляді впорядкованої структури, визначеної у вигляді рядків і стовпців і називаної відношенням;
всі значення є скалярами. Це означає, що для будь-якого рядка й стовпця будь-якого відношення існує одне й тільки одне значення;
всі операції виконуються над цілим відношенням, і результатом їхнього виконання також є ціле відношення. Цей принцип називається замиканням
11. Компоненти РБД
Формулюючи принципи реляційної моделі, доктор Кодд вибрав термін "відношення" (relation), тому що, на його думку, цей термін однозначний (у той час як, наприклад, термін "таблиця" має безліч різних видів - таблиця в тексті, електронна таблиця й ін.). Досить поширене наступна омана: реляційна модель названа так тому, що вона визначає зв'язки між таблицями. Насправді, назва цієї моделі походить від відносин (таблиць бази даних), що лежать у її основі.
Відносини зручно представляти у вигляді таблиць. На рис. 2.2.3 представлена таблиця (відношення ступеня 5), що містить деякі відомості про працівників гіпотетичного підприємства. Рядки таблиці відповідають кортежам. Кожен рядок фактично являє собою опис одного об'єкта реального світу (у цьому випадку працівника), характеристики якого знаходяться в стовпцях. Можна провести аналогію між елементами реляційної моделі даних й елементами моделі "сутність-зв'язок". Реляційні відносини відповідають наборам сутностей, а кортежі - сутностям. Тому, також як й у моделі "сутність-зв'язок" стовпці в таблиці, що представляють реляційне відношення, називають атрибутами.
Рисунок 2.2.3 - Основні компоненти реляційного відношення.
Кожен атрибут визначений на домені, тому домен можна розглядати як безліч припустимих значень даного атрибута.
Кілька атрибутів одного відношення й навіть атрибути різних відносин можуть бути визначені на тому самому домені. У прикладі, показаному на рис.2.2.3 атрибути "Оклад" й "Премія" визначені на домені "Гроші". Тому, поняття домену має семантичне навантаження: дані можна вважати порівнянними тільки тоді, коли вони ставляться до одному домену. Таким чином, у розглянутому нами прикладі порівняння атрибутів "Табельний номер" й "Оклад" є семантично некоректним, хоча вони й містять дані одного типу.
Поіменована безліч пар "ім'я атрибута - ім'я домену" називається схемою відношення. Потужність цієї безлічі - називають ступенем або "арністю" відношення. Набір поіменованих схем відношень представляє схему бази даних.
Атрибут, значення якого однозначно ідентифікує кортежі, називається ключовим (або просто ключем). У нашому випадку ключем є атрибут "Табельний номер", оскільки його значення унікально для кожного працівника підприємства. Якщо кортежі ідентифікуються тільки зчепленням значень декількох атрибутів, то говорять, що відношення має складений ключ.
Відношення може містити кілька ключів. Завжди один із ключів оголошуються первинним, його значення не можуть оновлюватися. Всі інші ключі відносини називаються можливими ключами. Атрибути, що представляють собою копії ключів інших відносин, називаються зовнішніми ключами.