Визначення 1. Хай дано відношення . Підмножина атрибутів відносини називатимемо потенційним ключем, якщо володіє наступними властивостями:

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

Властивістю ненадмірності - ніяка підмножина в не володіє властивістю унікальності.

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

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

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

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

Табельний номер | Прізвище | Зарплата

1 | Іванов | 1000

2 | Петров | 2000

3 | Сидоров | 3000

Таблиця 4 Відношення "Співробітники"

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

Спробуємо представити це відношення в іншому вигляді, змінивши найменування атрибутів:

A | B | C

1 | Іванов | 1000

2 | Петров | 2000

3 | Сидоров | 3000

Пред'явимо кому-небудь цю таблицю і не повідомимо значення найменувань атрибутів. Очевидно, що неможливо судити, не розуміючи значення даних, може або не може в цьому відношенні з'явитися, наприклад, кортеж (1, Петров, 3000). Якби, до речі, такий кортеж з'явився (що, на перший погляд, цілком можливо, оскільки не порушується унікальність кортежів), то ми точно змогли б сказати, що не є альтернативним ключем - жоден з атрибутів по окремості. Але ми не зможемо сказати, що ж є первинним ключем.

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

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

Цілісність сутностей

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

Це визначає наступне правило цілісності сутностей:

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

Зовнішні ключі

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

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

Номер постачальника | Назва постачальника | Номер деталі | Назва деталі | Кількість що поставляється

1 | Іванов | 1 | Болт | 100

1 | Іванов | 2 | Гайка | 200

1 | Іванов | 3 | Гвинт | 300

2 | Петров | 1 | Болт | 150

2 | Петров | 2 | Гайка | 250

3 | Сидоров | 3 | Гвинт | 1000

Таблиця 5 Відношення "Постачальники і деталі", що поставляються

Потенційним ключем цього відношення може виступати пара атрибутів {"Номер постачальника", "Номер деталі"} - в таблиці вони виділені курсивом.

Приведений спосіб зберігання даних володіє рядом недоліків.

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

Далі, як відобразити факт, що деякий постачальник, наприклад Петров, тимчасово припинив поставки деталей? Якщо ми видалимо всі кортежі, в яких зберігається інформація про поставки цього постачальника, то ми втратимо дані про самого Петрова як про потенційноно постачальника. Вийти з цього положення, залишивши у відношенні кортеж типу (2, Петров, NULL, NULL, NULL) ми не можемо, оскільки атрибут "Номер деталі" входить до складу потенційного ключа і не може містити null-значень. Те ж саме відбудеться,