Однак в реляційних базах даних це не прийняте. Ім'я схеми відношення в таких базах даних завжди співпадає з ім'ям відповідного відношення-примірника. У класичних реляційних базах даних після визначення схеми бази даних змінюються тільки відносини-примірники. У них можуть з'являтися нові і віддалятися або модифікуватися існуючі кортежі. Однак в багатьох реалізаціях допускається і зміна схеми бази даних: визначення нових і зміна існуючих схем відношення. Це прийнято називати еволюцією схеми бази даних.

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

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

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

4.2. Фундаментальні властивості відносин

Зупинимося тепер на деяких важливих властивостях відносин, які виходять з приведених раніше визначень:

4.2.1. Відсутність кортежів-дублікатів

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

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

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

4.2.2. Відсутність впорядкованості кортежів

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

4.2.3. Відсутність впорядкованості атрибутів

Атрибути відносин не впорядковані, оскільки по визначенню схема відношення є безліч пар {ім'я атрибута, ім'я домену}. Для посилання на значення атрибута в кортежі відношення завжди використовується ім'я атрибута. Ця властивість теоретично дозволяє, наприклад, модифікувати схеми існуючих відносин не тільки шляхом додання нових атрибутів, але і шляхом видалення існуючих атрибутів. Однак в більшості існуючих систем така можливість не допускається, і хоч впорядкованість набору атрибутів відношення явно не потрібно, часто як неявний порядок атрибутів використовується їх порядок в лінійній формі визначення схеми відношення.

4.2.4. Атомарність значень атрибутів

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

Можна сказати, що тут ми маємо бінарне відношення, значеннями атрибута ВІДДІЛИ якого є відносини. Помітимо, що початкове відношення СПІВРОБІТНИКИ є нормалізованим варіантом відношення ВІДДІЛИ:

СОТР_НОМЕР | СОТР_ІМЯ | СОТР_ЗАРП | СОТР_ОТД_НОМЕР

2934 | Іванов | 112,000 | 310

2935 | Петров | 144,000 | 310

2936 | Сидоренко | 92,000 | 313

2937 | Федоров | 110,000 | 310

2938 | Іванова | 112,000 | 315

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

Зарахувати співробітника Кузнєцова (пропуск номер 3000, зарплата 115,000) у відділ номер 320 і

Зарахувати співробітника Кузнєцова (пропуск номер 3000, зарплата 115,000) у відділ номер 310.

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

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

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

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