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

В деяких випадках при ієрархічному і мережному представлені зростання

бази даних може привести до порушення логічної організації даних. Такі

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

Недоліки ієрархічної і мережної моделей привели до появи нової, реляційної моделі даних, створеної Коддом у 1970 році .Реляційна модель була спробою спростити структуру бази даних. У ній були відсутні явні покажчики на предків і нащадків, а всі дані були представлені у виді простих таблиць, розбитих на рядки і стовпці.

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

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

У реляційної базі даних інформація організована у виді таблиць,

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

Двохвимірні таблиць в математиці отримали назву відношення .

У кожного стовпця в таблиці є своє ім'я, що звичайно служить заголовком

стовпця. Усі стовпці в одній таблиці повинні мати унікальні імена, однак

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

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

при формуванні таблиці. У будь-якій таблиці завжди є як мінімум один

стовпець.

Як правило, не вказується максимально допустиме число стовпців у

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

На відміну від стовпців, рядки таблиці не мають визначеного порядку. Це

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

Рядки таблиці утворюють данні різного формату і різного типу, тобто

можна стверджувати, що рядки таблиці є кортежами.

У таблиці може міститися будь-як кількість рядків. Цілком припустиме

існування таблиці з нульовою кількістю рядків. Така таблиця називається

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

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

Найменша одиниця даних реляційної моделі - це окреме атомарне

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

Опис кожного відношення складається з імені відношення (підмет), за

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

Кодд у 1985 році сформулював 12 правил, яким повинна задовольняти

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

Дванадцять правил Кодда, яким повинна відповідати реляційна СКБД.

1. Правило інформації.

Вся інформація в базі даних повинна бути надана винятково на логічному

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

2. Правило гарантованого доступу.

Логічний доступ до всіх і кожного елементу даних (атомарному значенню)

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

комбінації імені таблиці, первинного ключа та імені стовпця.

3. Правило підтримки недійсних значень.

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

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

4. Правило динамічного каталогу, заснованого на реляційній моделі.

Опис бази даних на логічному рівні необхідно представити в тому ж виді,

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

5.Правило вичерпної підмови даних.

Реляційна система може підтримувати різні мови і режими взаємодії з

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

6. Правило відновлення представлень.

Усі представлення, які теоретично можна обновити, повинні бути доступні для відновлення.

7. Правило додавання, відновлення і вилучення.

Можливість працювати з відношенням як з одним операндом повинна

існувати не тільки при читанні даних, але і при додаванні, відновленні вилученні даних.

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

Прикладні програми й утиліти для роботи з даними повинні на логічному

рівні залишатися недоторканими при будь-яких змінах методів збереження даних чи методів доступу до них.

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

Прикладні програми й утиліти для роботи з даними повинні на логічному

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

10. Правило незалежностіумов цілісності.

Повинна існувати можливість визначати умови цілісності, специфічні для

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

11. Правило незалежності поширення.

Реляційна СКБД не повинна залежати від потреб конкретного клієнта.

12. Правило одиничності.