• Ключі відіграють важливу роль у реляційній базі даних.
• Він використовується для однозначної ідентифікації будь-якого запису або рядка даних у таблиці. Він також використовується для встановлення та ідентифікації зв’язків між таблицями.

Наприклад, Ідентифікатор використовується як ключ у таблиці Student, оскільки він унікальний для кожного студента. У таблиці PERSON номер_паспорта, номер_ліцензії, номер соціального страхування є ключами, оскільки вони унікальні для кожної особи.

Типи ключів:

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

• Це перший ключ, який використовується для однозначної ідентифікації одного екземпляра сутності. Сутність може містити кілька ключів, як ми бачили в таблиці PERSON. Ключ, який найбільше підходить із цих списків, стає первинним ключем.
• У таблиці EMPLOYEE ID може бути первинним ключем, оскільки він унікальний для кожного співробітника. У таблиці EMPLOYEE ми навіть можемо вибрати License_Number і Passport_Number як первинні ключі, оскільки вони також унікальні.
• Для кожної сутності вибір первинного ключа базується на вимогах і розробниках.

2. Ключ-кандидат

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

Наприклад: У таблиці EMPLOYEE id найкраще підходить для первинного ключа. Решта атрибутів, як-от SSN, Passport_Number, License_Number тощо, вважаються потенційними ключами.

3. Супер ключ

Суперключ — це набір атрибутів, який може однозначно ідентифікувати кортеж. Суперключ — це надмножина ключа-кандидата.

Наприклад: У наведеній вище таблиці EMPLOYEE для (EMPLOEE_ID, EMPLOYEE_NAME) імена двох співробітників можуть збігатися, але їхні EMPLYEE_ID не можуть збігатися. Отже, ця комбінація також може бути ключовою.

Суперключем буде EMPLOYEE-ID (EMPLOYEE_ID, EMPLOYEE-NAME) тощо.

4. Зовнішній ключ

• Зовнішні ключі - це стовпець таблиці, який використовується для вказівки на первинний ключ іншої таблиці.
• Кожен співробітник працює в певному відділі компанії, а працівник і відділ — це дві різні сутності. Тому ми не можемо зберігати інформацію про відділ у таблиці співробітників. Ось чому ми зв’язуємо ці дві таблиці через первинний ключ однієї таблиці.
• Ми додаємо первинний ключ таблиці DEPARTMENT, Department_Id, як новий атрибут у таблиці EMPLOYEE.
• У таблиці EMPLOYEE Department_Id є зовнішнім ключем, і обидві таблиці пов’язані.

5. Альтернативний ключ

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

Наприклад, зв'язок працівника має два атрибути Employee_Id і PAN_No, які діють як ключі-кандидати. У цьому відношенні Employee_Id вибирається як первинний ключ, тому інший ключ-кандидат, PAN_No, діє як альтернативний ключ.

fmoviez

6. Складений ключ

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

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

7. Штучний ключ

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

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