в йому номер 0. Почнемо розгляд правил з цього останнього або нульового. p align="justify">
Правило 0 (фундаментальне правило). Реляційна система для управління базами даних повинна використовувати виключно реляційні можливості. Іншими словами для управління реляційними базами даних СУБД не може надавати які-ліб О не реляційні операції. Дане правило є дуже жорстким і, на жаль, порушується багатьма СУБД. Навіть всіма визнаний і стандартизований мова SQL містить елементи "нереляційних". Можна сказати, що правило 0 вимагає безумовного виконання наступних дванадцяти правил.
Правило 1 (правило інформації). Вся інформація в реляційної базі даних (включаючи імена таблиць і стовпців) представляється у явному вигляді тільки на логічному рівні і лише у вигляді значень, що зберігаються в таблицях. Звідси до речі випливає і умова відсутності порядку рядків і стовпців в таблицях, оскільки впорядкована послідовність додає додаткову можливість зберігання інформації. Зауважимо також, що схема бази даних також повинна зберігатися в табличному вигляді. Згадка ж у правилі 1 логічного рівня означає, що інформація про об'єкти нижчого рівня, наприклад, індексах, має бути виключена з моделі даних.
Також слід зауважити, що з першого правила, що не явно випливає і вимога першої нормальної форми: атомарность даних, що зберігаються на перетині рядків і стовпців таблиці. Дійсно, якщо не вимагати атомарності, тоді в шпальтах можуть зберігатися і складні структури, наприклад ті ж таблиці. Оскільки дані одного стовпця повинні належати одному і тому ж домену, доведеться погодитися, що домен повинен містити безліч таблиць, але ці таблиці також мають бути описані відповідними схемами і можуть у свою чергу містити таблиці. Навряд чи таку структуру можна назвати простою (явною) і зручною для проектування. У результаті ми можемо отримати ієрархічну систему. Сучасні СУБД, проте, обходять вимога першої нормальної форми і допускають зберігання в шпальтах таблиць
Правило 2 (правило гарантованого доступу). Логічний доступ до всіх і кожного елементу даних в реляційної базі даних забезпечується комбінацією імені таблиці, імені стовпця і значенням первинного ключа. Це вимога передбачає:
В· Унікальність імені таблиці в базі даних.
В· Унікальність імені стовпця в таблиці.
В· Унікальність первинного ключа, принаймні, в межах однієї таблиці.
У реальних СУБД можуть бути присутніми додаткові параметри доступу, наприклад ім'я користувача, власника даної бази. Крім цього, оскільки система може працювати з декількома базами даних, в якості ще одного параметра може бути ім'я бази даних. Н...
