Таблиця бази даних є структурою, що зберігає інформацію в організованому, консистентному, надійному та зручному для пошуку вигляді. Існують різні типи баз даних для різних варіантів використання. Тип, на якому ми зосередимося, це реляційна база даних.
Ключі — одна з основних вимог реляційної моделі бази даних. Ключі потрібні в системі управління базами даних (DBMS), щоб забезпечити організованість, точність і легкість доступу до даних.
Ключі допомагають унікально ідентифікувати записи в таблиці, що запобігає дублюванню та забезпечує цілісність даних. Ключі також встановлюють зв’язки між різними таблицями, що дозволяє ефективно здійснювати запити та керувати даними [1, 2].
Різні типи ключів у базах даних
1. Первинний ключ
Первинний ключ у кожній таблиці забезпечує унікальність кожного запису в цій таблиці.
Унікальні значення дозволяють розкрити потенціал, який надають бази даних. У базі даних унікальне значення — це значення, яке не з’являється в жодному іншому рядку в певному стовпці. Таким чином, для цього конкретного поля є тільки одне значення.
- Первинний ключ є унікальним ідентифікатором для кожного запису в таблиці
- Він повинен містити унікальні значення і не може містити NULL
- Первинний ключ не змінюється з часом
Приклад: У таблиці клієнтів стовпець CustomerID може бути первинним ключем, оскільки кожен клієнт має унікальний ідентифікатор.
2. Зовнішній ключ
Зв’язок між первинним і зовнішнім ключем дозволяє створювати реляційні бази даних, де дані з кількох таблиць можуть бути взаємопов’язані і запитувані в значущий спосіб. Зовнішні ключі є важливими для підтримки послідовності та узгодженості в базах даних.
- Зовнішній ключ — це поле (або набір полів) в одній таблиці, яке посилається на первинний ключ іншої таблиці.
- Воно встановлює зв'язок між двома таблицями та використовується для підтримки референтної цілісності.
- Зовнішній ключ може мати дублікати та NULL значення (якщо це не обмежено явно).
Приклад: У таблиці продажів стовпець CustomerID може бути зовнішнім ключем, що посилається на CustomerID в таблиці клієнтів, встановлюючи зв'язок між замовленнями та клієнтами.
3. Складений ключ
Іноді для створення ключа потрібно використовувати два або більше полів. Це називається складеним ключем. Комбінація значень у цих стовпцях повинна бути унікальною для кожного рядка в таблиці.
- Складений ключ є первинним або унікальним ключем, який складається з кількох стовпців для унікальної ідентифікації запису.
- Його використовують, коли жоден окремий стовпець не може унікально ідентифікувати рядок.
Приклад: Уявіть, що у вас немає стовпця CustomerID у таблиці клієнтів. Комбінація Name та SocialSecurityNumber може бути використана як складений ключ для створення стовпця CustomerID.
Складені ключі можуть підвищити складність при управлінні зв’язками з зовнішніми ключами в інших таблицях. Наприклад, будь-яка таблиця, що посилається на таблицю клієнтів, повинна включати як Name, так і SocialSecurityNumber як зовнішні ключі.
Однак складений ключ є корисним, коли жоден окремий стовпець не може унікально ідентифікувати запис, а комбінація стовпців надає необхідну унікальність.
4. Кандидатний ключ
Кандидатний ключ представляє унікальну комбінацію одного або кількох стовпців в таблиці, яка може унікально ідентифікувати кожен рядок і може потенційно стати первинним ключем. Кожен кандидатний ключ гарантує, що жодні два рядки в таблиці не можуть мати однакову комбінацію значень для стовпців кандидатного ключа.
Один кандидатний ключ обирається як первинний ключ, а інші стають альтернативними ключами.
- Кандидатний ключ — це поле або комбінація полів, яке може служити первинним ключем, що означає, що він може унікально ідентифікувати записи в таблиці.
- Таблиця може мати кілька кандидатних ключів, але один із них обирається як первинний.
Приклад: У таблиці Customer стовпець CustomerID і SocialSecurityNumber можуть бути кандидатними ключами, оскільки кожен унікально ідентифікує клієнта. (але тут ми припускаємо, що SocialSecurityNumber у таблиці клієнтів не може бути NULL).
CustomerID найбільше підходить для первинного ключа, тому він обирається як первинний ключ. Інші кандидатні ключі називаються альтернативними ключами.
5. Альтернативний ключ
Унікальний ідентифікатор для запису, який не є первинним ключем. Його можна використовувати як другий спосіб пошуку даних у таблиці.
(Альтернативний ключ — це кандидатний ключ, який не обраний як первинний ключ.)
- Альтернативний ключ — це будь-який кандидатний ключ, який не обраний як первинний.
- Він надає альтернативний спосіб унікальної ідентифікації записів у таблиці.
Приклад: Якщо CustomerID обраний як первинний ключ у таблиці клієнтів, то SocialSecurityNumber може бути альтернативним ключем.
Він відповідає критеріям унікальності та ідентифікації.
Кожен з цих ключів відіграє важливу роль у визначенні структури та зв'язків у базі даних, забезпечуючи консистентність даних, унікальність та референтну цілісність. [3,4,5]
Ключі для сховищ даних
У цій частині статті ми поговоримо про ключі, які використовуються в сховищах даних.
1. Природний ключ
У сховищі даних природний ключ — це ключ, що безпосередньо походить з даних джерела та має вбудоване бізнес-значення. Він також відомий як бізнес-ключ або ключ домену. Цей ключ зазвичай є унікальним ідентифікатором, що використовується в операційній системі джерела, наприклад, CustomerID.
- Природний ключ має бізнес-значення і використовується у бізнесі для ідентифікації сутності.
- Природні ключі походять з системи джерела та часто використовуються для відстеження записів.
- У деяких випадках природні ключі можуть змінюватися в системі джерела з бізнесових причин (наприклад, реорганізація кодів). Це може спричинити проблеми в підтримці зв'язків у сховищі даних.
- Дані з кількох джерел можуть спричинити дублювання, якщо той самий природний ключ існує в кількох системах (наприклад, дві системи з різними клієнтами, але з однаковим CustomerID).
Природні ключі не генеруються. Вони походять з систем джерел.
Приклад: У таблиці клієнтів CustomerID є природним ключем з системи джерела.
2. Замінний ключ
Замінний ключ — це значення, що генерується системою (може бути GUID, послідовність, унікальний ідентифікатор тощо) без бізнес-значення (на відміну від природних ключів, таких як номери соціального страхування чи CustomerID), що використовується для унікальної ідентифікації запису в таблиці. Ключ може складатися з одного або кількох стовпців (тобто складений ключ).
Замінні ключі широко використовуються в сховищах даних, оскільки вони покращують продуктивність запитів, спрощують з'єднання та дозволяють ефективно відстежувати дані, навіть коли ключі системи джерела змінюються.
Приклад: У таблиці клієнтів CustomerSurrogateKey є замінним ключем, що генерується системою.
3. Ключ версії
Ключ версії використовується, коли історичні дані зберігаються шляхом створення нової версії рядка кожного разу, коли змінюється значуща атрибутика.
Кожна версія запису має унікальний ключ версії, який допомагає відстежувати різні версії тієї ж бізнес-сутності з часом.
Приклад: У таблиці клієнтів:
Якщо ми хочемо відстежувати історичні дані кожного клієнта (наприклад, зміни адреси) в таблиці customer, ми додамо ключ версії, який збільшуватиметься з кожною новою версією даних клієнта. [3, 6, 7, 8]
ДЖЕРЕЛА:
[3] ChatGPT
[4] https://airbyte.com/data-engineering-resources/database-keys
[5] https://databasetown.com/6-types-of-keys-in-database/
[7] https://www.ibm.com/docs/en/ida/9.1.2?topic=keys-surrogate
[8] https://www.geeksforgeeks.org/surrogate-key-in-dbms/
Перекладено з: Database Keys and Keys for Data Warehouse