logo
Конспект лекцій з дисципліни

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    5. Правило вичерпної підмови даних. Реляційна система може підтримувати різні мови і режими взаємодії з користувачем (наприклад, режим питань і відповідей). Однак повинна існувати принаймні одна мова, оператори якої підтримують такі елементи:

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

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

  3. обробку даних (інтерактивну і програмну);

  4. умови цілісності;

  5. ідентифікацію прав доступу;

  6. границі трансакцій (початок, завершення і скасування).

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

    2. Правило додавання, відновлення і вилучення. Можливість працювати з відношенням як з одним операндом повинна існувати не тільки при читанні даних, але і при доповненні, відновленні і вилученні даних.

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

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

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

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

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

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

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

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

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

Правило 6 дозволяє показувати різним користувачам різні фрагменти структури бази даних.

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

Правила 8 і 9 стверджують, що конкретні способи реалізації чи збереження доступу, які використовуються в СКБД, і навіть зміни структури таблиць бази даних не повинні впливати на можливість користувача працювати з даними.

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

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

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

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

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

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

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

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

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

Друга вимога називається вимогою цілісності по посиланнях.

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

Степінь відношення - це число його атрибутів. Відношення степеня один називають унітарним, степеня два - бінарним, ступеня три - тернарним, ... , а ступеня n - n-арним.

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

Переваги реляційної бази :

  1. Незалежність від фізичного рівня подання;

  2. Зручність і розуміння організації даних користувачами;

  3. Максимальна гнучкість при обробці непередбачених запитів;

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