ОРГАНІЗАЦІЯ ТА УПРАВЛІННЯ БАЗАМИ ДАНИХ

ПІДХІД ДО ПРОЕКТУВАННЯ БД

американський вчений Кодд у 1970 р. Створена Коддом теорія нормалізації

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

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

Тому, будь-яку ІЛМ спочатку проектують як нормалізовану реліцяційну модель, а потім відображують на ту модель, яку підтримує вибрана СУБД.

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

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

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

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

По-іншому:

Домен - множина можливих значень конкретного атрибута.
Найбільш правильним інтуїтивним трактуванням поняття домену є розуміння домену як допустимої потенційної множини значень даного типу.
Відношення - фундаментальне поняття реляційної моделі даних. З цієї причини модель і називається реляційною (від англійського relation - відношення). Підмножина декартов добуток одного або більше доменів.
Атрибут - властивість об'єкта, явища або процесу. Приклади атрибутів: прізвище, ім'я.
Кортеж - елемент відношення, це відображення імен атрибутів в значення, взяті з відповідних доменів. Кінцеве безліч кортежів утворює відношення. Якщо відношення створюється з n доменів, то кожен кортеж має n компонент.

домену (або типу, якщо поняття домену не підтримується)}.

Ступінь або

"арність" схеми відношення - потужність цієї множини. Ступінь відношення СПІВРОБІТНИКИ дорівнює чотирьом, тобто воно є 4-арним. Якщо всі атрибути одного відношення визначені на різних доменах, осмислено використовувати для іменування атрибутів імена відповідних доменів (не забуваючи, звичайно, про те, що це є всього лише зручним способом іменування і не усуває відмінності між поняттями домену та атрибута).

Схема БД (в структурному сенсі) - це набір іменованих схем відносин.

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

Відношення - це множина кортежів, які відповідають одній схемі відношення.

відношення, а рядками - кортежі відношення-екземпляри; в цьому випадку імена

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

Отже, реляційна БД — це набір взаємозв'язаних відношень.
Відношення можна поділити на два класи: об’єктні й зв'язкові.

Об'єктні відношення зберігають дані про інформаційні об’єкти предметної області.
Наприклад:
ДЕТАЛЬ (код деталі, назва деталі, маса деталі, собівартість) – об'єктне відношення

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

якими встановлюються зв'язки між ними.
Наприклад, розглянемо ще одне об’єкте відношення

ВЕРСТАТ (код верстата, фірма-виготовлювач, дата введення в експлуатацію, початкова вартість)
Тоді відношення ТЕХНОЛОГІЯ (код деталі, код верстата) буде зв’язковим між двома об’єктними відношеннями ДЕТАЛЬ і ВЕРСТАТ.

У зв’язковому відношенні можуть дублюватися ключові атрибути крім ключів, за якими встановлюється зв’язок у зв’язковому відношенні; можуть бути ще й інші атрибути, які функціонально залежать від цього зв’язку Наприклад, ТЕХНОЛ0ГІЯ (код верстата, код деталі, код технологічної операції, норма часу обробки деталі на верстаті). Ключі в зв’язкових відношеннях називаються зовнішніми, або вторинними оскільки вони пов’язані з первинними ключами інших відношень.
Реляційна модель накладає на зовнішні ключі обмеження для забезпечення цілісності даних, яке називається посилковою цілісністю Це означає, що кожному зовнішньому ключу має відповідати рядок якогось об’єктного відношення. Без такого обмеження може статися, що зовнішній ключ посилається на об'єкт про який нічого не відомо.

У реляційній БД накладається ще одне обмеження – відношення мають бути нормалізовані.

має бути оптимальною, тобто такою, яка є найбільш стійкою при

внесенні змін у дані та зв'язки між ними Отже, в ненормалізованому відношенні можуть виникнути аномалії, пов’язані з виконанням операцій підтримки його в актуальному стані Виявити фактичний прояв тієї чи іншої аномалії можна. лише врахувавши конкретну семантику даних.

Приклад конкретного відношення:
КОМПАНІЯ (номер працівника, номер відділу, керівник, тип контракту)

1. Аномалія поновлення. Заміна керівника відділу призведе до необхідності внесення змін і модифікацій по кожному працівнику даного відділу Отже, для підтримання узгодженості даних необхідно виконати зміну не лише в кортежі бази, а цілий ряд змін, що може розглядатись як аномалія, оскільки характер самої зміни повинен стосуватися лише одного певного запису БД.

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

тоді разом з інформацією про них у БД буде втрачено

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

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

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

процес декомпозиції початкового відношення (на практиці: таблиці) відповідно до алгоритму

нормалізації на кілька простіших відношень меншої розмірності на базі функціональних залежностей.

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

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

Апарат нормалізації також розробив Едгар Франк Кодд. Кожна нормальна форма обмежує тип допустимих залежностей між атрибутами. Кодд виділив три нормальні форми (скорочена назва - 1НФ, 2НФ і 3НФ). Найбільш досконала з них - 3НФ. Зараз вже відомі й визначені 4НФ, 5НФ, 6НФ.

– зведення відношень до першої нормальної форми (1НФ, 1NF).


Відношення

в 1НФ мають відповідати таким вимогам:

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

одиниця вимірювання, характеристика: тип, сорт, розмір).
У цьому відношенні атрибут «Характеристика»

є неатомарннм, тому потрібно позбутися складового атрибута й перетворити його в три атомарних атрибути. В результаті зведення до 1НФ відношення набере вигляду

МАТЕРІАЛ (код матеріалу, назва матеріалу, одиниця вимірювання, тип, сорт, розмір).

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

функціональних залежностей неключових атрибутів від ключів, аналізують ці залежності з

метою вилучення неповних функціональних залежностей.

Визначення 1. Атрибут В залежить від А у деякому відношенні R тоді, коли в кожний момент часу одному й тому самому значенню А відповідає не більше як одне значення В.

Графічно функціональна залежність зображується так: А —> В.

Цій залежності відповідає співвідношення 1:1 між атрибутами. Наприклад, як між атрибутами (код деталі —> назва деталі), (код верстата —> назва верстата).

Сутність поняття функціональної й неповної функціональних залежностей.

такого ключа може бути повною або частковою. Якщо маємо відношення

R(А*, В*, С, О), ключ якого складається з двох атрибутів А і В, тобто є складним (знаком (*) позначено ключові атрибути), то функціональні залежності в такому відношенні можуть мати такий вид:

Атрибут С перебуває в повній функціональній залежності, тобто залежить від всього складного ключа, а атрибут D — в неповній, оскільки залежить лише від його складової частини атрибута В.

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

Виконавши декомпозицію відношення R, отримаємо замість одного два відношення, які будуть перебувати в 2НФ:

і кожний неключовий атрибут функціонально повно залежить від складного ключа.

Побудуємо

діаграму функціональних залежностей:

З діаграми видно, що атрибути «Назва матеріалу» і «Ціна матеріалу» залежать не від всього ключа, а лише від його частини, а атрибут «Норма витрат матеріалу на деталь» залежить від всього ключа, тобто перебуває в повній функціональній залежності.

Отже, початкове відношення НОРМА розбивається на два відношення:

МАТЕРІАЛ (код матеріалу, назва матеріалу, ціна матеріалу)

НОРМА_ВИТРАТ (код деталі, код матеріалу, норма витрат матеріалу на деталь).

У базі даних замість одного відношення НОРМА необхідно зберігати два відношення МАТЕРІАЛ і НОРМА_ВИТРАТ, які перебувають у 2НФ.

Приклад: дано відношення НОРМА (виділено ключові атрибути)
НОРМА (код деталі, код матеріалу, назва матеріалу, ціна матеріалу, норма витрат матеріалу на деталь).

зберігаються в таблицях із складним (композитним) ключем не залежали лише

від частини ключа:

Схема бази даних повинна відповідати вимогам першої нормальної форми.

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

у БД, яка перебуває в 2НФ, значно менша, ніж у

ненормалізовану БД.

Так, при зміні ціни якогось матеріалу необхідно знайти лише відповідний матеріал у відношенні МАТЕРІАЛ і замінити лише один атрибут «Ціна матеріалу»; якщо ж БД ненормалізована, потрібно знайти всі деталі, на які витрачається даний матеріал, і виконати відповідні в усіх знайдених запи­сах зміни. При цьому якщо буде пропущено хоча б одну деталь, то це приз­веде до протиріччя в даних.

2НФ повністю виключає можливість виникнення протиріччя даних, а також економить пам'ять при зберіганні відношень у пам'яті ЕОМ.

Наприклад, у випадку зберігання в базі даних ненормалізованого відношення НОРМА інформація про один і той самий матеріал буде дублюватись у БД стільки разів, на скільки різних деталей він витрачається. Отже, буде значне надмірне дублювання даних і великі перевитрати пам'яті.

потрібно аналізувати на присутність транзитивних залежностей.

Транзитивна залежність — це

залежність між неключовими атрибутами. Нехай є відношення R(А*, С, D), у якому атрибут D безпосередньо не залежить від ключового атрибута А, а залежить від неключового атрибута С, який залежить від А. Тоді атрибут D транзитивно залежить від А.

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

Відношення перебуває в 3НФ, якщо воно перебуває в 2НФ і кожний неключовий атрибут нетранзитивно залежить від первинного ключа.

Наприклад, відношення ВИКЛАДАЧ (табельний N, прізвище, посада, оклад, кафедра, телефон) перебуває в 2НФ, але вміщує транзитивну залежність:

В результаті зведення до 3НФ отримуємо два відношення: ВИКЛАДАЧ (табельний N, прізвище, посада, оклад, кафедра) і КАФЕДРА (код кафедри, телефон кафедри).

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

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

Отже, третя нормальна форма (3НФ, 3NF) вимагає, аби дані в таблиці залежали винятково від основного ключа:
Схема бази даних повинна відповідати всім вимогам другої нормальної форми.
Будь-яке поле, що залежить від основного ключа та від будь-якого іншого поля, має виноситись в окрему таблицю.

вивчає залежності ключових атрибутів від неключових; якщо такі залежності існують,

то їх потрібно вилучити.

Приклад відношення АВТОМОБІЛЬ (модель автомобіля, кількість циліндрів у двигуні, країна-виготовлювач). У цьому відношенні існують такі залежності:

Отож, ключовий атрибут «модель автомобіля» залежить від неключового атрибута «країна-виготовлювач». Тому при зведенні до БКНФ початкове відношення буде розбито на такі відношення:

АВТОМОБІЛЬ (модель автомобіля, кількість циліндрів у двигуні);

ВИРОБНИК (країна-виготовлювач, модель автомобіля).

Відношення перебуває в БКНФ, якщо воно перебуває в 3НФ і в ньому відсутні залежності ключів від неключових атрибутів.

Відношення, яке з перебуває в БКНФ, завжди є відношенням у 3НФ. Але, навпаки, відношення в 3НФ не завжди можна привести до нормальної форми Бойса-Кодда, не втративши залежності між його атрибутами.

такі залежності:
Зведення відношення R до 3НФ дасть два відношення:

R1(місто, адреса), R2(адреса, індекс). Вони перебувають у 3НФ, але не є відношеннями в НФБК, оскільки у відношенні R існує залежність індекс —> місто, тобто відношення в 3НФ не завжди є відношенням у НФБК.

Якщо звести це відношення до НФБК, то отримується відношення R1(місто, адреса), R2(індекс, місто), в яких будуть відображені не всі залежності початкового відношення. Так, не буде відображено залежності індекс—> адреса, а саме індекс позначає відділення зв’язку, що обслуговує адресатів якоїсь вулиці певного міста.

Отож, зведення до НФБК може призвести до втрати важливих для початкового відношення залежностей, а об’єднання отриманих в результаті такої декомпозиції відношень не дасть початкового відношення. Тому при зведенні до НФБК необхідно ретельно вивчати всі залежності, виконувати його лише тоді, коли виконується така вимога: «об’єднання без втрат»

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

кожної функціональної залежності є потенційним ключем. Якщо це правило не

виконується, тоді щоб привести вказане відношення до НФБК його слід розділити на два відношення шляхом двох операцій проекції на кожну функціональну залежність детермінант, якої не є потенційним ключем.
Проекція без атрибутів залежної частини такої функціональної залежності;
Проекція на всі атрибути цієї функціональної залежності.

Визначення НФБК не потребує жодних умов попередніх нормальних форм. Якщо проводити нормалізацію послідовно, то в переважній більшості випадків при досягненні 3НФ автоматично будуть задовольнятися вимоги НФБК. 3НФ не збігається з НФБК лише тоді, коли одночасно виконуються такі 3 умови:
Відношення має 2 або більше потенційних ключів.
Ці потенційні ключі складні (містять більш ніж один атрибут)
Ці потенційні ключі перекриваються, тобто мають щонайменше один спільний атрибут.

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

є різновидом функціональної залежності, їй відповідає співвідношення 1:Б між атрибутами
Атрибут А багатозначно визначає атрибут В у відношенні R(A, В, С), якщо В залежить лише від А при будь-яких його комбінаціях з іншими атрибутами відношення R. Графічно це позначають так А —>> В.

Якщо залежність А —>> В єдина у відношенні R, то відношення перебуває в 3НФ.
Якщо у відношенні присутні А —>> В і А —>> С, то відношення R потрібно розкласти на два інших відношення: R1 (А, В) і R2 (А, С).

Приклад. Нехай задано відношення СПІВРОБІТНИК(табельний номер, державна нагорода, прізвище, ім’я та по-батькові члена сім’ї, код родинних відносин)
У цьому відношенні виконуються багатозначні залежності
табельний номер —>> державна нагорода,
табельний номер —>> прізвище, ім'я та по-батькові члена сім’ї

Для того щоб виключити надлишкове дублювання, початкове відношення необхідно розкласти на два відношення: ВИНАГОРОДИ (табельний номер, державна нагорода), СІМ’Я (табельний номер, ім’я та по батькові члена сім’ї, код родинних відносин)

і Y —>> X є тривіальною, а залежність типів Х —>> Y і Y –/–>> X

нетривіальною.

Визначення. Відношення R перебуває в 4НФ, якщо в структурі багатозначної залежності, визначеної на множині атрибутів, є лише тривіальні і/або такі нетривіальні багатозначні залежності, що ліва частина будь-якої з них є ключем.

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

Приклад. Дано відношення ВИКЛАДАЧ (прізвище, група, предмет), у якому присутні багатозначні залежності (призвище—>>група), (прізвище—>> предмет).
У цьому відношенні є дві незалежні одна від одної багатозначні залежності, які можуть спричинити аномалії. Якщо у викладача з’являється нова група, доводиться додавати не один кортеж, а стільки, скільки предметів він читає в цій групі. Аналогічна ситуація спостерігається з уведенням нового предмета.

Тому потрібно виконати декомпозицію початкового відношення на два таких: ВИКЛАДАЧ_ГРУПА (прізвище, група), ВИКЛАДАЧ_ПРЕДМЕТ (прізвище, предмет).

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

чого, окрім надмножини ключа-кандидата. Вважається, що таблиця знаходиться у 4НФ тоді, і тільки тоді, коли вона знаходиться в НФБК, та багатозначні залежності є функціональними залежностями. Четверта нормальна форма усуває небажані структури даних — багатозначні залежності.

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

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

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

П'ята нормальна форма (5НФ, 5NF, PJ/NF) вимагає, аби не було не тривіальних залежностей об'єднання, котрі б не витікали із обмежень ключів. Вважається, що таблиця в п'ятій нормальній формі, тоді, і тільки тоді, коли вона знаходиться в 4НФ, та кожна залежність об'єднання зумовлена її ключами-кандидатами.

Нормальна форма домен/ключ (доменно-ключова нормальна форма – ДКНФ, DKNF). Ця нормальна форма вимагає, аби в схемі не було інших обмежень окрім ключів та доменів.

Шоста нормальна форма. Таблиця знаходиться у 6NF, якщо вона знаходиться у 5NF та задовольняє вимозі відсутності нетривіальних залежностей. Зазвичай 6NF ототожнюють з DKNF.

дванадцяти) запропонованих Едгаром Коддом, піонером реляційної моделі для баз даних, спроектовані для визначення того

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

0. Фундаментальне правило (Foundation Rule)
Реляційна СУБД має бути здатною повністю керувати базою даних, використовуючи зв'язки між даними.

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

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

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

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

4. Правило доступу до системного каталогу на основі реляційної моделі (Dynamic On-line Catalog Based on the Relational Model)
Словник даних має зберігатись у формі реляційних таблиць, і СУБД повинна підтримувати доступ до нього за допомогою стандартних мовних засобів, тих самих, що використовуються для роботи з реляційними таблицями, які містять дані користувача.

5. Правило повноти підмови маніпулювання даними (Comprehensive Data Sublanguage Rule)
Система управління реляційними базами даних має підтримувати хоча б одну реляційну мову, яка:
а) має лінійний синтаксис,
б) може використовуватись інтерактивно і в прикладних програмах,
в) підтримує операції визначення даних, визначення уявлень, маніпулювання даними (інтерактивні та програмні), обмежувачі цілісності, управління доступом та операції управління трансакціями (begin, commit і rollback).

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

видалення даних.

7. Правило високорівневих операцій модифікації даних (High-level Insert, Update, and Delete)
Операції вставки, модифікації і видалення даних мають підтримуватись не тільки щодо одного рядку реляційної таблиці, але й щодо будь-якої множини рядків.

8. Правило фізичної незалежності даних (Physical Data Independence)
Додатки не повинні залежати від використовуваних способів зберігання даних на носіях, від апаратного забезпечення комп'ютерів, на яких знаходиться реляційна база даних.

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

10. Правило незалежності контролю цілісності (Integrity Independence)
Вся інформація, необхідна для підтримки цілісності, має бути у словнику даних. Мова для роботи з даними має виконувати перевірку вхідних даних і автоматично підтримувати цілісність даних.

перебувати на кількох комп'ютерах, і це не повинно впливати на

додатки. Перенесення бази даних на інший комп'ютер не повинне впливати на додатки.

12. Правило узгодженості мовних рівнів (The Nonsubversion Rule)
Якщо використовується низькорівнева мова доступу до даних, вона не повинна ігнорувати правила безпеки і правила цілісності, які підтримуються мовою більш високого рівня.