This article needs additional citations for verification. (February 2024) |
В проектировании баз данных составной ключ — это потенциальный ключ , состоящий из двух или более атрибутов [1] [2] [3] (столбцов таблицы), которые вместе уникально идентифицируют вхождение сущности (строку таблицы).
Составной ключ — это составной ключ, для которого каждый атрибут, составляющий ключ, сам по себе является внешним ключом. [4] [5]
Составные ключи имеют преимущества, аналогичные преимуществам естественного ключа , поскольку они часто состоят из нескольких атрибутов естественного ключа.
Составные ключи используют меньше дискового пространства по сравнению с определением столбца суррогатного ключа , это происходит потому, что составной ключ уже существует как атрибуты в таблице и не нуждается в определении в таблице только для целей уникальной идентификации. Это упрощает таблицу и также экономит место.
Составные ключи легко реализовать в схеме базы данных , поскольку их составные части уже являются именованными элементами в базе данных. Когда они также являются естественными ключами, они часто интуитивно понятны для сценариев реального мира. Они часто используются, когда несоставной ключ не всегда однозначно идентифицирует запись. Например, личное имя часто, но не всегда, может быть уникальным в данной базе данных, и некоторые другие поля, такие как дата рождения, могут быть добавлены, чтобы сделать уникальность намного более вероятной.
Бизнес-требования и правила могут меняться, что может изменить формат определенных сущностей реального мира. Составные ключи формируются из нескольких естественных ключей, которые связаны с реальным миром, и с изменением их формата в реальном мире их формат в базе данных также будет изменен. Это неудобно, так как количество атрибутов составного ключа изменится, и все внешние ключи должны будут обновиться.
Составной ключ состоит из нескольких атрибутов, и составной ключ будет упоминаться в нескольких таблицах как внешний ключ, это использует много дискового пространства, поскольку несколько столбцов хранятся как внешний ключ вместо, возможно, одного. Это усложняет схему, а запросы становятся более затратными для ЦП, поскольку для каждого соединения СУБД должна будет сравнивать три атрибута вместо, возможно, одного в случае одного естественного ключа.
Примером является сущность, которая представляет модули, которые каждый студент посещает в университете. Сущность имеет studentID и moduleCode в качестве своего первичного ключа . Каждый из атрибутов, составляющих первичный ключ, является простым ключом, поскольку каждый представляет собой уникальную ссылку при идентификации студента в одном случае и модуля в другом, поэтому этот ключ является составным ключом.
Напротив, используя тот же пример, представьте, что мы идентифицировали студента по его firstName + lastName (предполагая, что у людей должны быть разные имена). В таблице, представляющей студентов, наш первичный ключ теперь будет firstName + lastName . Поскольку студенты могут иметь одинаковое firstName или одинаковую lastName, эти атрибуты не являются простыми ключами. Первичный ключ firstName + lastName для студентов является составным ключом.