Составной ключ

Candidate key with two or more attributes in a database

В проектировании баз данных составной ключ — это потенциальный ключ , состоящий из двух или более атрибутов [1] [2] [3] (столбцов таблицы), которые вместе уникально идентифицируют вхождение сущности (строку таблицы).

Составной ключ — это составной ключ, для которого каждый атрибут, составляющий ключ, сам по себе является внешним ключом. [4] [5]

Преимущества

Составные ключи имеют преимущества, аналогичные преимуществам естественного ключа , поскольку они часто состоят из нескольких атрибутов естественного ключа.

Хранилище

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

Проще в реализации и использовании

Составные ключи легко реализовать в схеме базы данных , поскольку их составные части уже являются именованными элементами в базе данных. Когда они также являются естественными ключами, они часто интуитивно понятны для сценариев реального мира. Они часто используются, когда несоставной ключ не всегда однозначно идентифицирует запись. Например, личное имя часто, но не всегда, может быть уникальным в данной базе данных, и некоторые другие поля, такие как дата рождения, могут быть добавлены, чтобы сделать уникальность намного более вероятной.

Недостатки

Изменения требований

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

Сложность и хранение

Составной ключ состоит из нескольких атрибутов, и составной ключ будет упоминаться в нескольких таблицах как внешний ключ, это использует много дискового пространства, поскольку несколько столбцов хранятся как внешний ключ вместо, возможно, одного. Это усложняет схему, а запросы становятся более затратными для ЦП, поскольку для каждого соединения СУБД должна будет сравнивать три атрибута вместо, возможно, одного в случае одного естественного ключа.

Пример

Примером является сущность, которая представляет модули, которые каждый студент посещает в университете. Сущность имеет studentID и moduleCode в качестве своего первичного ключа . Каждый из атрибутов, составляющих первичный ключ, является простым ключом, поскольку каждый представляет собой уникальную ссылку при идентификации студента в одном случае и модуля в другом, поэтому этот ключ является составным ключом.

Напротив, используя тот же пример, представьте, что мы идентифицировали студента по его firstName + lastName (предполагая, что у людей должны быть разные имена). В таблице, представляющей студентов, наш первичный ключ теперь будет firstName + lastName . Поскольку студенты могут иметь одинаковое firstName или одинаковую lastName, эти атрибуты не являются простыми ключами. Первичный ключ firstName + lastName для студентов является составным ключом.

Смотрите также

Ссылки

  1. ^ Коннолли, Томас М.; Бегг, Кэролин Э. (2015). "12.3.4 Ключи". Системы баз данных: практический подход к проектированию, внедрению и управлению (6., глобальное издание). Бостон Колумбус Индианаполис: Pearson. стр. 416. ISBN 978-1-292-06118-4.
  2. ^ Elmasri, Ramez; Navathe, Sham (2017). "17.4 Индексы по нескольким ключам". Основы систем баз данных (Седьмое, глобальное издание). Бостон Колумбус Индианаполис Нью-Йорк Сан-Франциско Хобокен Амстердам Кейптаун Дубай Лондон Мадрид Милан Мюнхен Париж Монреаль Торонто Дели Мехико Сан-Паулу Сидней Гонконг Сеул Сингапур Тайбэй Токио: Pearson. стр. 661. ISBN 978-1-292-09761-9.
  3. ^ Коронель, Карлос; Моррис, Стивен (2015). "Глоссарий". Системы баз данных: проектирование, реализация и управление (12-е изд.). Cengage Learning. стр. 770. ISBN 978-1-305-62748-2.
  4. ^ Дункан, Джойс; Рэкли, Лесли; Уокер, Александрия (1995), Дункан, Джойс; Рэкли, Лесли; Уокер, Александрия (ред.), «Шаг 340 — Улучшение требуемой логической модели данных», SSADM на практике: Текст версии 4 , Лондон: Macmillan Education UK, стр.  61–70 , doi :10.1007/978-1-349-10341-6_6, ISBN 978-1-349-10341-6, получено 2024-10-25
  5. ^ Сикора, ЗМ (1997), Сикора, ЗМ (ред.), «Реализация проекта», Oracle Database Principles , Лондон: Macmillan Education UK, стр.  74–84 , doi :10.1007/978-1-349-14693-2_7, ISBN 978-1-349-14693-2, получено 2024-10-25
  • Составные обратные функциональные свойства: для эквивалентного понятия в семантической паутине
  • Технические требования к реляционной базе данных, ключи: обзор различных типов ключей в СУРБД
  • Различные типы ключей в базе данных: обзор всех типов ключей, используемых в СУБД
Retrieved from "https://en.wikipedia.org/w/index.php?title=Composite_key&oldid=1260309586"