uk %D0%A3%D0%BD%D1%96%D0%BA%D0%B0%D0%BB%D1%8C%D0%BD%D0%B8%D0%B9 %D0%BA%D0%BB%D1%8E%D1%87

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

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

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

Резюме

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

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

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

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

Простий: Ключ, зроблений лише з одного атрибуту.
Зчеплений (англ. concatenated): Ключ, зроблений з понад одного атрибуту, з'єднані разом як єдиний ключ, як-от частина чи ціле ім'я зі згенерованим системою числом наприкінці, як часто використовується для електронних адрес.
Складений: Ключ, зроблений із принаймні двох атрибутів або простих ключів, лише прості ключі існують у складеному.
Композитний (англ. composite): Ключ, який містить принаймні один складений із принаймні одним іншим атрибутом або простим ключем (це розширення складеного ключа).
Природний: Ключ, зроблений із даних, які існують поза поточною базою даних. Іншими словами, дані не згенеровані системою, як-от номер соціального страхування, імпортований із іншої системи.
Сурогатний: Штучний ключ, зроблений із даних, які призначені чи згенеровані системою, коли існує інший потенційний ключ. Сурогатні ключі зазвичай є числовими значеннями ідентифікаторів та часто використовуються з міркувань продуктивності^{[джерело не вказане 3802 дні]}.
Потенційний: Ключ, який може стати первинним.
Первинний ключ: Ключ, який обрано первинним. Лише один ключ у сутності вибирається первинним. Це ключ, якому дозволено мігрувати до інших сутностей для визначення відношень, які існують між сутностями. Коли модель даних інстанціюється у фізичну базу даних, це ключ, який система найбільше використовує при доступі до таблиці, чи з'єднанні таблиць разом при виборі даних.
Альтернативний: Непервинний ключ, який може використовуватися для визначення лише одного рядка в таблиці. Альтернативні ключі можуть використовуватися як первинні в однотабличній вибірці.
Зовнішній: Унікальний ключ, який мігрував до іншої сутності.

У найосновнішому визначенні «ключ — унікальний ідентифікатор»^[1], тому унікальний ключ є плеоназмом. Ключі, що знаходяться в їх початковій сутності, є унікальними в цій сутності. Ключі, що мігрують до іншої сутності, можуть бути чи не бути унікальними, залежно від конструкції та їх використання в іншій таблиці. Зовнішні ключі можуть бути первинним у іншій таблиці; наприклад, PersonID може стати EmployeeID у таблиці Employee. У цьому випадку EmployeeID є і зовнішнім ключем, і унікальним первинним, це означає, що таблиця має відношення 1:1. У випадку, коли сутність осіб містить ID біологічного батька, ID батька не очікується унікальним, оскільки батько може мати понад одну дитину.

Ось приклад первинного ключа, що стає зовнішнім у пов'язаній таблиці. ID мігрує з таблиці Автор до таблиці Книга.

  Схема таблиці Автор:
    Автор(ID, Ім'я, Адреса, Народження)

  Схема таблиці Книга:
    Книга(ISBN, AuthorID, Назва, Видавець, Ціна)

Тут ID слугує первинним ключем таблиці «Автор», але також AuthorID слугує зовнішнім ключем у таблиці «Книга». Зовнішній ключ слугує посиланням, а відтак і зв'язком між двома пов'язаними таблицями у цій простій базі даних.

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

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

На унікальні ключі так само, як і на первинні, можуть логічно посилатися зовнішні ключі, але більшість РСКБД дозволяють обмеження зовнішнього ключа лише на первинний ключ.

Визначення унікальних ключів у SQL

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

  ALTER TABLE <ідентифікатор таблиці> 
      ADD [ CONSTRAINT <ідентифікатор обмедення> ] 
      UNIQUE ( <вираз колонки> {, <вираз колонки>}… )

Також унікальні ключі можуть визначатись як частина інструкції SQL CREATE TABLE.

  CREATE TABLE table_name (
     id_col   INT,
     col2     CHARACTER VARYING(20),
     key_col  SMALLINT NOT NULL,
     …
     CONSTRAINT key_unique UNIQUE(key_col),
     …
  )

  CREATE TABLE table_name (
     id_col  INT  PRIMARY KEY,
     col2    CHARACTER VARYING(20),
     …
     key_col  SMALLINT NOT NULL UNIQUE,
     …
  )

Відмінності від обмежень первинних ключів

Відмінності між обмеженнями первинних ключів й унікальності:

Обмеження первинного ключа

Первинний ключ не може дозволяти NULL (первинний ключ не може визначатися на колонках, які дозволяють NULL).
Кожна таблиця не може мати понад один первинний ключ.
На деяких РСКБД первинний ключ за замовчуванням генерує кластерний індекс.

Обмеження унікальності

Обмеження унікальності може визначатися на колонках, які дозволяють NULL.
Кожна таблиця може мати багато унікальних ключів.
На деяких РСКБД унікальний ключ за замовчуванням генерує некластерний індекс.

Зверніть увагу, що, на відміну від обмеження PRIMARY KEY, обмеження UNIQUE не означає NOT NULL для колонок, які беруть участь у обмеженні. NOT NULL повинно бути вказано, щоби зробити колонку(и) ключовим(и). Можливо поставити обмеження UNIQUE на нульові колонки, але стандарт SQL стверджує, що обмеження не гарантує унікальності таких колонок (унікальність не дотримується для рядків, де будь-яка з колонок містить NULL).

Відповідно до стандарту SQL^[2], обмеження унікальності не дотримує унікальності за наявності NULL, а тому може містити кілька рядків з ідентичними сполученнями NULL і не-NULL значень — однак, не всі РСКБД реалізують цю функцію відповідно до стандарту SQL^[3]^[4].

Див. також

Примітки

↑ Awad, Elias (1985), Systems Analysis and Design (вид. 2-е), Richard D. Irwin, Inc., ISBN 0-256-02824-9
↑ Bouman, Roland P. Summary of ANSI/ISO/IEC SQL. XCDSQL (англійською) . Архів оригіналу за 5 травня 2007. Процитовано 19 грудня 2018. {{cite web}}: Проігноровано |розділ= (довідка)
↑ Constraints — SQL Database Reference Material — Learn sql, read an sql manual, follow an sql tutorial, or learn how to structure an SQL query!. www.sql.org. Процитовано 16 серпня 2018.
↑ Comparison of different SQL implementations. troels.arvin.dk. Процитовано 16 серпня 2018.

Посилання

Relation Database terms of reference, Keys. rdbms.opengrass.net (англійською) . Процитовано 19 грудня 2018.{{cite web}}: Обслуговування CS1: Сторінки з параметром url-status, але без параметра archive-url (посилання)

[1] Awad, Elias (1985), Systems Analysis and Design (вид. 2-е), Richard D. Irwin, Inc., ISBN 0-256-02824-9

[2] Bouman, Roland P. Summary of ANSI/ISO/IEC SQL. XCDSQL (англійською) . Архів оригіналу за 5 травня 2007. Процитовано 19 грудня 2018. {{cite web}}: Проігноровано |розділ= (довідка)

[3] Constraints — SQL Database Reference Material — Learn sql, read an sql manual, follow an sql tutorial, or learn how to structure an SQL query!. www.sql.org. Процитовано 16 серпня 2018.

[4] Comparison of different SQL implementations. troels.arvin.dk. Процитовано 16 серпня 2018.

[1]

[2]

[3]

[4]