Зовнішній складовий ключ. Бази даних. Резюме основних ключів

У цій статті ми спробуємо розглянути все, що стосується ключів у SQL:навіщо потрібні, створення, обмеження ключів. Загалом: буде нудно 😉

План на сьогодні такий:

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

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

Первинний ключ

Стовпець, який у базі даних має бути унікальним позначають первинним ключем. Первинний ключ або primary key означає, що у таблиці значення колонки primary key може повторюватися. Таким чином, цей ключ дозволяє однозначно ідентифікувати запис у таблиці не боячись при цьому, що значення стовпця повторитися. Відразу приклад: припустимо, у Вас є таблиця користувачів. У цій таблиці є поля: ПІБ, рік народження, телефон. Як ідентифікувати користувача? Таким параметрам як ПІБ та телефон довіряти не можна. Адже у нас може бути кілька користувачів не лише з однаковим прізвищем, а й з ім'ям. Телефон може змінюватися з часом і користувач з номером телефону може виявитися не тим, хто у нас у базі даних.

Ось для цього і вигадали первинний ключ. Одного разу надали унікальний ідентифікатор і все. У mySqlна прикладі якої ми виконуємо всі приклади з поля AUTO_INCREMENTне можна задати, якщо не вказати, що це первинний ключ.

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

Зовнішній ключ ( foreign key)

Є ще зовнішній ключ (foreign key). Його ще називають посилальним. Він необхідний зв'язування таблиць між собою.

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

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

Створення зовнішнього ключа

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

Складовий ключ (Composite key)

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

Трапляються ситуації, коли при вставці в таблицю потрібно перевіряти запис на унікальність відразу по кількох полях. Ось для цього і придуманий складовий ключ. Для прикладу я створю просту таблицю з composite key , щоб показати синтаксис:

Create table test(field_1 int, field_2 text, field_3 bigint, primary key (field_1, field_3));

У прикладі вище два поля об'єднані в складовий ключ і таблиці не буде записів з цими однаковими полями.

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

На малюнку представлена ​​таблиця (ставлення ступеня 5), що містить деякі відомості про працівників гіпотетичного підприємства. Рядки таблиці відповідають кортежам. Кожен рядок фактично є описом одного об'єкта реального світу (в даному випадку працівника), характеристики якого містяться в стовпцях. Реляційні відносини відповідають наборам сутностей, а кортежі – сутностям. Стовпці в таблиці, що представляє реляційне ставлення, називають атрибутами.

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

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

Первинний ключ- у реляційній моделі даних один з потенційних ключів відношення, вибраний як основний ключ (або ключ за замовчуванням).

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

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

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

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

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

Атрибути, що є копією ключів інших відносин, називаються зовнішніми ключами.

Наприклад, зв'язок між відносинами ВІДДІЛ і СПІВРОБІТНИК створюється шляхом копіювання первинного ключа "Номер_відділу" з першого відношення до другого. Таким чином, щоб отримати список працівників даного підрозділу, необхідно: 1) З таблиці ВІДДІЛ встановити значення атрибуту "Номер_відділу" , що відповідає даному "Найменуванню_відділу". 2) вибрати з таблиці СПІВРОБІТНИК всі записи, значення атрибута "Номер_відділу"яких дорівнює отриманому на попередньому кроці. Для того, щоб дізнатися, в якому відділі працює співробітник, потрібно виконати зворотну операцію: 1) Визначаємо "Номер_відділу"з таблиці СПІВРОБІТНИК. 2) За отриманим значенням знаходимо запис у таблиці ВІДДІЛ.

18. Нормалізація в реляційних БД, поняття нормальної форми під час проектування баз даних.

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

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

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

Функціональні залежності.

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

19. 1НФ: Основні визначення та правила перетворення.

Для обговорення першої нормальної форми необхідно дати два визначення:

Простий атрибут - атрибут, значення якого атомарні (неподільні).

Складний атрибут - виходить з'єднанням декількох атомарних атрибутів, які можуть бути визначені на одному або різних доменах (його називають вектор або агрегат даних).

Визначення першої нормальної форми:

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

Розглянемо приклад:

У базі даних відділу кадрів підприємства необхідно зберігати відомості про службовців, які можна спробувати подати щодо

СЛУЖАЧИЙ (НОМЕР_СЛУЖАЧОГО, ІМ'Я, ДАТА_НАРОДЖЕННЯ, ІСТОРІЯ_РОБОТИ, ДІТИ).

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

 ІСТОРІЯ_РОБОТИ (ДАТА_ПРИЙОМУ, НАЗВА, ІСТОРІЯ_ЗАРПЛАТИ),

 ІСТОРІЯ_ЗАРПЛАТИ (ДАТА_ПРИЗНАЧЕННЯ, ЗАРПЛАТА),

 ДІТИ (ІМ'Я_ДИТИНИ, РІК_НАРОДЖЕННЯ).

Їхній зв'язок представлений на рис. 3.3.

Рис.3.3. Початкове ставлення.

Для приведення вихідного відношення СЛУЖАЮЧИЙ до першої нормальної форми необхідно декомпозувати його на чотири відносини, оскільки це показано на наступному малюнку:

Рис.3.4. Нормалізована безліч відносин.

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

Алгоритм нормалізації описаний Е.Ф.Коддом так:

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

20. 2НФ: Основні визначеннята правила перетворення.

Дуже часто первинний ключ відношення включає кілька атрибутів (у такому разі його називають складовим) - див., наприклад, відношення ДІТИ, показане на рис. 3.4 питання 19. При цьому запроваджується поняття повної функціональної залежності.

Визначення:

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

Приклад:

Нехай є відношення ПОСТАВКИ (N_ПОСТАЧАЛЬНИКА, ТОВАР, ЦІНА).
Постачальник може постачати різні товари, а той самий товар може поставлятися різними постачальниками. Тоді ключ відношення - "N_постачальника + товар". Нехай всі постачальники поставляють товар за тією ж ціною. Тоді маємо такі функціональні залежності:

• N_постачальника, товар -> ціна
• товар -> ціна

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

• ПОСТАВКИ (N_ПОСТАЧАЛЬНИКА, ТОВАР)
• ЦІНА_ТОВАРУ (ТОВАР, ЦІНА)

Таким чином, можна дати

Визначення другої нормальної форми: Відношення знаходиться в 2НФ, якщо воно знаходиться в 1НФ і кожен неключовий атрибут функціонально залежить від ключа.

21. 3НФ: Основні визначеннята правила перетворення.

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

Визначення:

Нехай X, Y, Z – три атрибути деякого відношення. У цьому X --> Y і Y --> Z, але зворотне відповідність відсутня, тобто. Z -/-> Y та Y -/-> X. Тоді Z транзитивно залежить від X.
Нехай є відношення ЗБЕРІГАННЯ ( ФІРМА, СКЛАД, ОБСЯГ), яке містить інформацію про фірми, що отримують товари зі складів, та обсяги цих складів. Ключовий атрибут - "фірма". Якщо кожна фірма може отримувати товар тільки з одного складу, то в цьому відношенні є такі функціональні залежності:

• фірма -> склад
• склад -> Об `єм

При цьому виникають аномалії:

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

Для усунення цих аномалій необхідно декомпозувати вихідне відношення на два:

• ЗБЕРІГАННЯ ( ФІРМА, СКЛАД)
• ОБСЯГ_СКЛАДУ ( Склад, ОБ `ЄМ)

Визначення третьої нормальної форми:

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

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

Що таке первинний ключ?

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

Що таке ключ?

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

Різниця між основним ключем та зовнішнім ключем

Основи первинного ключа та зовнішнього ключа

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

Відношення первинного ключа та зовнішнього ключа

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

Дублюючі значення первинного ключа та зовнішнього ключа

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

NULL первинного ключа та зовнішнього ключа

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

Тимчасова таблиця первинного ключа та зовнішнього ключа

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

Видалення основного ключа та зовнішнього ключа

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

Первинний або зовнішній ключ: порівняльна таблиця

Резюме основних ключів

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

Останнє оновлення: 27.04.2019

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

Загальний синтаксис встановлення зовнішнього ключа на рівні таблиці:

FOREIGN KEY (стовпець1, стовпець2, ... стовпецьN) REFERENCES головна_таблиця (стовпець_головної_таблиці1, стовпець_головної_таблиці2, ... стовпець_головної_таблиціN)

Для створення обмеження зовнішнього ключа після FOREIGN KEY вказується стовпець таблиці, який представляє зовнішній ключ. А після ключового слова REFERENCES вказується ім'я пов'язаної таблиці, а потім у дужках ім'я зв'язаного стовпця, на який вказуватиме зовнішній ключ. Після виразу REFERENCES йдуть вирази ON DELETE та ON UPDATE , які задають дію при видаленні та оновленні рядка з головної таблиці відповідно.

Наприклад, визначимо дві таблиці та зв'яжемо їх за допомогою зовнішнього ключа:

CREATE TABLE Customers (Id INT PRIMARY KEY AUTO_INCREMENT, Age INT, FirstName VARCHAR(20) NOT NULL, LastName VARCHAR(20) NOT NULL, Phone VARCHAR(20) NOT NULL UNIQUE); CREATE TABLE Orders (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Customers (Id));

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

За допомогою оператора CONSTRAINT можна встановити ім'я для обмеження зовнішнього ключа:

CREATE TABLE Orders (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, CONSTRAINT orders_custonmers_fk FOREIGN KEY (CustomerId) REFERENCES Customers (Id));

ON DELETE та ON UPDATE

За допомогою виразів ON DELETE та ON UPDATE можна встановити дії, які виконуються відповідно при видаленні та зміні зв'язаного рядка з головної таблиці. Як дія можуть використовуватися такі опції:

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

SET NULL: при видаленні або оновленні зв'язаного рядка з головної таблиці встановлює значення NULL для стовпчика зовнішнього ключа. (У цьому випадку стовпець зовнішнього ключа має підтримувати встановлення NULL)

RESTRICT : відхиляє видалення чи зміну рядків у головній таблиці за наявності пов'язаних рядків у залежній таблиці.

NO ACTION : те саме, що й RESTRICT .

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

Каскадне видалення

Каскадне видалення дозволяє при видаленні рядка з головної таблиці автоматично видалити всі зв'язані рядки із залежної таблиці. Для цього застосовується опція CASCADE:

CREATE TABLE Orders (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Customers (Id) ON DELETE CASCADE);

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

Встановлення NULL

У разі встановлення для зовнішнього ключа опції SET NULL необхідно, щоб стовпець зовнішнього ключа допускав значення NULL:

CREATE TABLE Orders (Id INT PRIMARY KEY AUTO_INCREMENT, CustomerId INT, CreatedAt Date, FOREIGN KEY (CustomerId) REFERENCES Customers (Id) ON DELETE SET NULL);

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

Що таке первинний ключ у БД

У базі даних первинний ключ таблиці - це з її стовпців (Primary key). Розберемося на прикладі, як це виглядає. Уявімо просте ставлення студентів університету (назвемо його "Студенти").

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

Простий та складовий первинний ключ

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

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

Зв'язки між відносинами

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

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

У двох відносинах прикладу бачимо поле ID. Це первинні ключі у базі даних цих таблиць. Як бачимо, успішність містить лише посилання на ці поля з інших таблиць без необхідності вказувати всю інформацію з них.

Природний та сурогатний ключ

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

Зовнішній ключ та цілісність даних у БД

Все вищевикладене призводить до зовнішнього ключа (Foreign key) і цілісності БД. Foreign key – це поле, що посилається на Primary key зовнішнього відношення. У таблиці успішності це стовпці "Студент" та "Дисципліна". Їхні дані відсилають нас до зовнішнім таблицям. Тобто поле "Студент" щодо "Успішність" - це Foreign key, а щодо "Студент" це первинний ключ у базі даних.

Важливим принципом побудови баз даних є їхня цілісність. І одне з її правил – цілісність за посиланнями. Це означає, що зовнішній ключ таблиці не може посилатися на неіснуючий Primary key іншого відношення. Не можна видалити з відношення "Студент" запис із кодом 1000 - Іванов Іван, якщо на неї посилається запис із таблиці успішності. У правильно побудованій БД при спробі видалення ви отримаєте помилку, що це поле використовується.

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