Правила Кодда - Студопедія
Тед Кодд 1969 року сформулював дванадцять правил, яким має відповідати справжня реляційна база даних. (Табл 11.1). Вони є напівофіційним визначенням поняття "реляційна база даних".
| 1.Правило інформації | Вся інформація в базі даних має бути представлена лише одним способом - у вигляді значень, що містяться в таблицях. |
| 2.Правило гарантованого доступу | Доступ до всіх та кожного елемента даних (атомарного значення) гарантовано забезпечується шляхом використання комбінації імені таблиці, імені стовпця та значення первинного ключа. |
| 3.Правило підтримки недійсних значень. | У цій реляційній базі даних має бути реалізована підтримка недійсних значень, які відрізняються від рядка символів нульової довжини, рядка пробільних символів, від нуля або будь-якого іншого числа та використовуються для представлення відсутніх даних незалежно від типу цих даних. |
| 4.Правило динамічного каталогу. | Опис структури бази даних на логічному рівні має бути представлено в тому ж вигляді, що й основні дані, щоб користувачі, які мають відповідні права, могли працювати з ним за допомогою тієї ж реляційної мови, яку вони застосовують для роботи з основними даними. |
| 5.Правило вичерпної підмови даних. | Реляційна система може підтримувати різні мови та режими взаємодії з користувачем. Однак має існувати принаймні одна мова, яка повною мірою підтримує такі елементи: n визначення даних; n визначення уявлень; n обробку даних (інтерактивну та програмну); n умови цілісності; nідентифікація прав доступу; n межі транзакцій (початок, завершення та скасування). |
| 6.Правило оновлення уявлень | Усі уявлення, які теоретично можна оновити, мають бути доступними для оновлення. |
| 7.Правило додавання, зміни та видалення. | Можливість працювати з ставленням як з цілим повинна існувати не тільки під час читання даних, але й при додаванні, зміні та видаленні даних. |
| 8. Правило незалежності фізичних даних | Прикладні програми для роботи з даними повинні логічно залишатися недоторканими при будь-яких змінах способів зберігання даних або методів доступу до них. |
| 9. Правило незалежності логічних даних. | Прикладні програми для роботи з даними повинні на логічному рівні залишатися недоторканими при внесенні до базових таблиць будь-яких змін, які теоретично дозволяють зберегти недоторканими дані, що містяться в цих таблицях. |
| 10. Правило незалежності умов цілісності. | Повинна існувати можливість визначати умови цілісності специфічно для конкретної реляційної бази даних, на підмові реляційної бази даних та зберігати їх у самій базі даних, а не в прикладній програмі. |
| 11. Правило незалежності поширення. | Реляційна СУБД має залежати від потреб конкретного клієнта. |
| 12. Правило єдиності | Якщо в реляційній системі є низькорівнева мова (яка обробляє один запис за один раз), то повинна бути відсутня можливість використання її для того, щоб обійти правила та умови цілісності, виражені реляційною мовою високого рівня (яка обробляє кілька записів за одинразів). |
Правило 2 вказує на роль первинних ключів при пошуку інформації у базі даних. Ім'я таблиці дозволяє знайти необхідну таблицю, ім'я стовпця дозволяє знайти необхідний стовпець, а значення первинного ключ дозволяє знайти рядок, що містить елемент даних, що шукається.
Правило 3 вимагає, щоб відсутні дані можна було надати за допомогою недійсних значень (NULL). Істотно, що використання нулів ініціює перехід із двозначної логіки (так/ні) на тризначну (так/ні/можливо).
Правило 4 говорить, що реляційна база даних має сама себе описувати. У реляційній базі даних існує два типи таблиць - таблиці користувача і системні таблиці. Користувацькі таблиці містять інформацію. Системні таблиці описують структуру самої бази даних, однак доступ до них можна отримати так само, як і до будь-яких інших таблиць.
Правило 5 вимагає, щоб СУБД використовувала мову реляційної бази даних, наприклад SQL, хоча явно SQL у правилі не згадано. Така мова має підтримувати всі основні функції СУБД – створення бази даних, читання та введення даних, реалізацію захисту бази даних тощо.
Правило 6 стосується уявлень, що є віртуальними таблицями. Віртуальні таблиці, на відміну «справжніх» таблиць, фізично не зберігаються у базі даних. У той самий час необхідно усвідомлювати, що віртуальні таблиці це копія деяких даних, поміщається до іншої таблицю. Коли ви змінюєте дані у віртуальній таблиці, тим самим змінюєте дані у базових таблицях. В ідеальній реляційній системі з віртуальними таблицями можна оперувати, як і з будь-якими іншими таблицями. Це одне з правил, які найскладніше реалізувати на практиці.
Правило 7 наголошує на тому, що бази данихза своєю природою орієнтовані на множини. Воно вимагає, щоб операції додавання, зміни та видалення можна було виконувати над безліччю рядків. Це правило забороняє реалізації, у яких підтримуються операції лише над одним рядком.
Правило 8 та 9 означають відділення користувача та прикладної програми від низькорівневої реалізації бази даних. Вони стверджують, що конкретні способи реалізації зберігання чи доступу, які у СУБД, і навіть зміни структури таблиць бази даних нічого не винні впливати на можливість користувача працювати з даними. Реляційна модель забезпечує незалежність даних на двох рівнях – фізичному та логічному. Фізична незалежність даних означає з погляду користувача, що представлення даних не залежить від способу їх фізичного зберігання. Логічна незалежність означає, що зміна взаємозв'язків між таблицями та рядками, їх структура не впливають на правильне функціонування програм та поточних запитів.
Правило 10 свідчить, що мова бази даних повинна підтримувати обмеження на дані, що вводяться, і на дії, які можуть бути виконані над даними. Цілісність - дуже складне і серйозне питання під час управління реляційними базами даних. Неузгодженість чи суперечливість даних може виникати внаслідок збою системи - проблеми з апаратним забезпеченням, помилки у програмному забезпеченні чи логічної помилки у додатках. Реляційні системи управління базами даних захищають дані від такого типу неузгодженості, гарантуючи, що команда буде виконана до кінця, або буде повністю скасована.
Інший тип цілісності, званий об'єктною цілісністю, пов'язані з коректним проектуванням бази даних. Об'єктна цілісність вимагає, щоб жоден первинний ключ не мавнульового значення.
Третій тип цілісності, званої посилальної цілісністю, означає несуперечність між частинами інформації, що повторюються у різних таблицях. Наприклад, якщо ви змінюєте неправильно введений номер картки страхового поліса в одній таблиці, інші таблиці, що містять цю інформацію, продовжують посилатися на старий номер, тому необхідно оновити і ці таблиці. Надзвичайно важливо, щоб при зміні інформації в одному місці вона відповідно змінювалася і в усіх інших місцях. Крім того, за визначенням Кодда, обмеження на цілісність мають:
- визначатися мовою високого рівня, що використовується системою для всіх інших цілей;
- Зберігатися у базі даних, а чи не у програмних додатках.
Ці можливості у тому чи іншому вигляді реалізовані у більшості СУБД.
Правило 11 свідчить, що мова бази даних має забезпечувати можливість роботи з розподіленими даними, розташованими інших комп'ютерних системах.
І, нарешті, правило 12 запобігає використанню інших можливостей для роботи з базою даних, крім мови бази даних, оскільки це може порушити її цілісність.
Дванадцять правил Кодда вважаються визначенням реляційної СУБД. Проте можна сформулювати і простішу визначення:
Реляційноїназивається база даних, в якій всі дані, доступні користувачеві, організовані у вигляді таблиць, а всі операції над даними зводяться до операцій над цими таблицями.
Чи не знайшли те, що шукали? Скористайтеся пошуком: