Сколько первичных ключей может быть в таблице

Сколько первичных ключей может быть в таблице

. Стоять я не могу. мои колени

Слабеют. душно! .. душно! ..

Где ключи? Ключи, ключи мои! ..

А. С. Пушкин. Скупой рыцарь, сцена III

Каждая сущность должна иметь признаки, которые ее описывают, в противном случае она просто не может существовать. Признак сущности, представляющий интерес называется атрибутом. Некоторые атрибуты сущности не только описывают, но и уникальным образом идентифицируют ее. Их называют первичным ключом. Первичный ключ (primary key) – это атрибут или группа атрибутов, однозначно идентифицирующая экземпляр сущности.

Если в сущности своего первичного ключа нет – следует создать дополнительный атрибут. Примером такого атрибута являются код автора, номер зачетной книжки студента. Такие ключи называют суррогатными, т.е. вне базы данных они не имеют

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

Рассмотрим кандидатов на первичный ключ сущности Автор. Здесь мож­но выделить следующие потенциальные ключи: «Автор#», «Номер паспорта», «Фамилия Имя Отчество» (сос­тавной).

Ключи могут быть составными, то есть содержащими несколько атрибутов.

Для того чтобы быть первичным, потенциальный ключ должен удовлетворять ряду требований:

• Уникальность

Два экземпляра не должны иметь одинаковых значений возможного ключа. Потенциальный ключ «Фамилия Имя Отчество» является плохим кандидатом, так как авторы могут быть полными тезками. Экземпляры же ключей «Автор#» и «Номер паспорта» являются уникальными.

• Компактность

Для обеспечения уникальности дополним ключ «Фамилия Имя Отчество» атрибутом «Адрес». Но при выборе первичного ключа предпочтение должно отдаваться более простым ключам, то есть ключам, содержащим меньшее количество атрибутов. Тогда ключи «Автор» и «Номер паспорта» предпочтительнее составного ключа «Фамилия Имя Отчество Адрес».

• Атрибуты не должны содержать null-значений.

Если допускается, что автор может, например, не иметь паспорта (например, у Федора Михайловича Достоевского какой номер пас- порта?), то ключ «Номер паспорта» не подойдет на роль первичного ключа. Если для обеспечения уникальности необходимо дополнить потенциальный ключ дополнительными атрибутами, то они не должны содержать нулевых значений. Дополняя ключ «Фамилия Ими Отчество» атрибутом «Адрес», нужно убедиться в том, что адреса всех авторов известны.

• Значение атрибутов ключа не должно меняться в течение всего времени существования экземпляра сущности.

Автор может выйти замуж и сменить фамилию, сменить паспорт. Поэтому «Номер паспорта» и «Фамилия Имя Отчество» не подходят по этому условию на роль первичного ключа.

Итак, наиболее подходящим первичным ключом сущности Автор является суррогатный атрибут «Автор#».

Каждая сущность должна иметь по крайней мере один потенциальный ключ. Многие сущности имеют только один потенциальный ключ. Такой ключ становится первичным. Но если сущность имеет более одного возможного ключа, то один из них становится первичным, а остальные – альтернативными, ключами. Альтернативный ключ – это потенциальный ключ, не ставший первичным.

Внешний ключ (Foreign key) – это атрибут или группа атрибутов одной сущности, которые могут служить в качестве первичного ключа для другой сущности. Говорят также, что внешний ключ одной сущности является ссылкой на первичный ключ другой сущности.

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

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

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

28 . Задайте первичный ключ: выберите сущность Автор, МП, выберите Properties, выберите вкладку Attributes, в области Attributes выберите Автор# , выберите флажком Primary UID , нажмите Ладно .

29 . Задайте первичный ключ: выберите сущность Книга, МП, выберите Properties, выберите вкладку Attributes, в области Attributes выберите Книга# , выберите флажком Primary UID , нажмите Ладно .

30 . Задайте первичный ключ: выберите сущность Издательство, МП, выберите Properties, выберите вкладку Attributes, в области Attributes выберите Издательство# , выберите флажком Primary UID , нажмите Ладно .

Обратите внимание, чтоатрибут первичного ключа Издательство# родительской сущности Издательство должен автоматически мигрировать в дочернюю сущность Книга.

31 . Задайте первичный ключ: выберите сущность З аказ, МП, выберите Properties, выберите вкладку Attributes, в области Attributes выберите Заказ# , выберите флажком Primary UID , нажмите Ладно .

32 . Задайте первичный ключ: выберите сущность Редактор, МП, выберите Properties, выберите вкладку Attributes, в области Attributes выберите Редактор# , выберите флажком Primary UID , нажмите Ладно .

Пред.	Уровень выше	След.
18.4.7. Атрибут	Начало | ToC	18.4.9. Нотация Баркера

Считается ли хорошей практикой использовать несколько PRIMARY KEY в одной таблице

PRIMARY KEY может быть только один, может вы хотели PRIMARY KEY (id, position, question) ? А смысл, если у вас есть id, который по сути им и является. Нужны дополнительные индексы — так и создавайте их отдельно, а в PK их совать не надо

16 дек 2015 в 15:19

Сделайте UNIQUE INDEX. Связь устанавливается на любой уникальный ключ/индекс. Это может быть PRIMARY KEY или UNIQUE INDEX

16 дек 2015 в 15:24
Правильно связь сделать по id, как ворон говорит.
16 дек 2015 в 15:34

Вообще ID в таблице для того и есть, что бы ссылаться на него, а не на какие либо еще данные в таблице. А foreign обеспечивает что в подчиненной таблице в поле могут быть только такие данные, которые есть в основной таблице

16 дек 2015 в 15:36

FOREIGN KEY, ссылаясь на ключевое поле в главной таблице (PRIMARY KEY или UNIQUE KEY), ссылается на всю запись. По ключу автоматом вытягиваются как за ниточку и все остальные поля. Не надо каждое поле индексировать без надобности. Однако остальные поля можно проиндексировать для увеличения скорости выборки, когда в запросе используются условия по этим полям.

16 дек 2015 в 15:47

2 ответа 2

Сортировка: Сброс на вариант по умолчанию

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

Первичный ключ должен быть таким, что бы за время жизни записи по возможности не меняться никогда. В некоторых случаях можно найти у сущности некий признак подходящий на роль первичного ключа. Например, двухбуквенные коды стран ( RU ), эти коды стандартизированы, применяются одинаково во всем мире, меняются только при геополитических изменениях, т.е. ключ меняется тогда, когда меняется сама сущность. При создании справочника стран такое поле можно делать первичным ключом. В случаях, когда, подходящего по свойствам признака нет — делают просто числовой ID.

Длинные текстовые поля очень плохие первичные ключи, потому, что в них легко могут быть банальные опечатки. И попытка исправить такую опечатку приведет к необходимости поменять это поле не только в этой таблице, но и во всех таблицах, ссылающихся на данную. А таких записей могут быть миллионы . Кроме того, сама политика FOREIGN KEY не позволит просто так изменить первичный ключ, если на него есть ссылки. База не может допустить что бы в подчиненных таблицах существовали записи со значениями ссылающихся полей отсутствующих в головной таблице. Следовательно перед изменением первичного ключа необходимо во всех подчиненных таблицах заранее поправить ссылки на новый ключ, но новый ключ в этот момент уже должен существовать в головной таблице. Единственным способом такого изменения, не нарушающего ссылки, является создание новой записи с новым значением ключа, правке всех ссылок и удалении записи со старым значением ключа.

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

Ограничения первичных и внешних ключей

Первичные ключи и внешние ключи — это два типа ограничений, которые можно использовать для обеспечения целостности данных в таблицах SQL Server. Это важные объекты базы данных.

Ограничения первичного ключа

Обычно в таблице есть столбец или сочетание столбцов, содержащих значения, уникально определяющие каждую строку таблицы. Этот столбец, или столбцы, называются первичным ключом (PK) таблицы и обеспечивает целостность сущности таблицы. Так как ограничения первичного ключа гарантируют уникальные данные, они часто определяются в столбце удостоверений.

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

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

• В таблице возможно наличие только одного ограничения по первичному ключу.
• Первичный ключ не может превышать 16 столбцов и общую длину ключа 900 байт.
• Индекс, созданный ограничением первичного ключа, не может привести к тому, что число индексов таблицы превышает 999 некластеризованных индексов и 1 кластеризованных индексов.
• Если кластеризованный или некластеризованный не указан для ограничения первичного ключа, кластеризованный используется, если в таблице нет кластеризованного индекса.
• Все столбцы с ограничением первичного ключа должны быть определены как не допускающие значения NULL. Если значение NULL не указано, все столбцы, участвующие в ограничении первичного ключа, имеют значение NULL.
• Если первичный ключ определен на столбце определяемого пользователем типа данных CLR, реализация этого типа должна поддерживать двоичную сортировку.

Foreign Key Constraints

Внешний ключ (FK) — это столбец или сочетание столбцов, которое применяется для принудительного установления связи между данными в двух таблицах с целью контроля данных, которые могут храниться в таблице внешнего ключа. Если один или несколько столбцов, в которых находится первичный ключ для одной таблицы, упоминается в одном или нескольких столбцах другой таблицы, то в ссылке внешнего ключа создается связь между двумя таблицами. Этот столбец становится внешним ключом во второй таблице.

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

Максимальное количество таблиц и столбцов, на которые может ссылаться таблица в качестве внешних ключей (исходящих ссылок), равно 253. SQL Server 2016 (13.x) увеличивает ограничение числа других таблиц и столбцов, которые могут ссылаться на столбцы в одной таблице (входящих ссылок), с 253 до 10 000. (Требуется уровень совместимости не менее 130.) Увеличение имеет следующие ограничения:

• Превышение 253 ссылок на внешние ключи поддерживается только для операций DML DELETE. Операции UPDATE и MERGE не поддерживаются.
• Таблица со ссылкой внешнего ключа на саму себя по-прежнему ограничена 253 ссылками на внешние ключи.
• Более 253 ссылок на внешний ключ в настоящее время недоступны для индексов columnstore, оптимизированных для памяти таблиц, Stretch Database или секционированных таблиц внешнего ключа.

Важно! Stretch Database устарел в SQL Server 2022 (16.x) и База данных SQL Azure. Эта функция будет удалена в будущей версии ядро СУБД. Избегайте использования этого компонента в новых разработках и запланируйте изменение существующих приложений, в которых он применяется.

Индексы в ограничениях внешнего ключа

В отличие от ограничений первичного ключа, создание ограничения внешнего ключа не автоматически создает соответствующий индекс. Тем не менее, часто возникает необходимость создания индекса для внешнего ключа вручную по следующим причинам:

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

Ссылочная целостность

Главная задача ограничения внешнего ключа состоит в управлении данными, которые могут быть сохранены в таблице внешнего ключа, но это ограничение контролирует также изменение данных в таблице первичного ключа. Например, при удалении строки для менеджера по продажам из таблицы Sales.SalesPerson , идентификатор которого используется в заказах на продажу в таблице Sales.SalesOrderHeader , ссылочная целостность двух таблиц будет нарушена. Заказы на продажу удаленного менеджера в таблице SalesOrderHeader станут недействительными без связи с данными в таблице SalesPerson .

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

Каскадная ссылочная целостность

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

NO ACTION
Ядро СУБД вызывает ошибку, а действие удаления или обновления строки в родительской таблице откатывается.

CASCADE
Соответствующие строки обновляются или удаляются из ссылающейся таблицы, если данная строка обновляется или удаляется из родительской таблицы. КАСКАД нельзя указать, если столбец метки времени является частью внешнего ключа или ключа, на который ссылается ссылка. ON DELETE CASCADE нельзя указать для таблицы с триггером INSTEAD OF DELETE. ON UPDATE CASCADE нельзя указать для таблиц с триггерами INSTEAD OF UPDATE.

SET NULL
Всем значениям, составляющим внешний ключ, присваивается значение NULL, когда обновляется или удаляется соответствующая строка в родительской таблице. Для выполнения этого ограничения внешние ключевые столбцы должны допускать значения NULL. Невозможно указать для таблиц с триггерами INSTEAD OF UPDATE.

SET DEFAULT
Все значения, составляющие внешний ключ, при удалении или обновлении соответствующей строки родительской таблицы устанавливаются в значение по умолчанию. Для выполнения этого ограничения все внешние ключевые столбцы должны иметь определения по умолчанию. Если столбец имеет значение NULL, и нет явного набора значений по умолчанию, NULL становится неявным значением по умолчанию столбца. Невозможно указать для таблиц с триггерами INSTEAD OF UPDATE.

Ключевые слова CASCADE, SET NULL, SET DEFAULT и NO ACTION можно сочетать в таблицах, имеющих взаимные ссылочные связи. Если ядро СУБД обнаруживает NO ACTION, он останавливается и откатывает связанные действия CASCADE, SET NULL и SET DEFAULT. Если инструкция DELETE вызывает сочетание действий CASCADE, SET NULL, SET DEFAULT и NO ACTION, все действия CASCADE, SET NULL и SET DEFAULT применяются перед ядро СУБД проверка для любых действий NO ACTION.

Триггеры и каскадные ссылочные действия

Каскадные ссылочные действия запускают триггеры AFTER UPDATE или AFTER DELETE следующим образом:

• Все каскадные ссылочные действия, прямо вызванные исходными инструкциями DELETE или UPDATE, выполняются первыми.
• Если есть какие-либо триггеры AFTER, определенные для измененных таблиц, эти триггеры запускаются после выполнения всех каскадных действий. Эти триггеры запускаются в порядке, обратном каскадным действиям. Если в одной таблице существует несколько триггеров, они запускаются в случайном порядке, если для таблицы не существует выделенный первый или последний триггер. Этот порядок определяется процедурой sp_settriggerorder.
• Если последовательности каскадных действий происходят из таблицы, которая была непосредственной целью действий DELETE или UPDATE, порядок запуска триггеров этими последовательностями действий не определен. Однако одна последовательность действий всегда запускает все свои триггеры до того, как это начнет делать следующая.
• Триггер AFTER таблицы, являвшейся непосредственной целью действий DELETE или UPDATE, запускается вне зависимости от того, были ли изменены хоть какие-нибудь строки. В этом случае ни на какие другие таблицы каскадирование не влияет.
• Если один из предыдущих триггеров выполняет операции DELETE или UPDATE над другими таблицами, эти операции могут вызывать собственные последовательности каскадных действий. Эти вторичные последовательности действий обрабатываются для каждой операции DELETE или UPDATE после выполнения всех триггеров первичных последовательностей действий. Этот процесс может рекурсивно повторяться для последующих операций DELETE или UPDATE.
• Выполнение операций CREATE, ALTER, DELETE или других операций языка DDL внутри триггеров может привести к запуску триггеров DDL. Это может привести к дальнейшим операциям DELETE или UPDATE, которые начнут дополнительные последовательности каскадных действий и запустят свои триггеры.
• Если в любой конкретной последовательности каскадных ссылочных действий произойдет ошибка, в этой последовательности не будут запущены никакие триггеры AFTER, а для операций DELETE или UPDATE, создаваемых этой последовательностью, будет выполнен откат.
• Таблица с триггером INSTEAD OF не может также содержать предложение REFERENCES, указывающее каскадное действие. Однако триггер AFTER целевой таблицы каскадного действия может выполнить инструкцию INSERT, UPDATE или DELETE для другой таблицы или представления, которое запустит триггер INSTEAD OF для этого объекта.

Следующие шаги

В следующей таблице перечислены общие задачи, связанные с ограничениями первичного ключа и внешнего ключа.

Задача	Статья
Описывает, как создать первичный ключ.	Создание первичных ключей
Описывает, как удалить первичный ключ.	Удаление первичных ключей
Описывает, как изменить первичный ключ.	Изменение первичных ключей
Описывается создание связей внешнего ключа	Создание связей по внешнему ключу
Описывает, как изменить связи внешнего ключа.	Изменение связей по внешнему ключу
Описывает, как удалить связи внешнего ключа.	Удаление связей по внешнему ключу
Описывает, как просматривать свойства внешнего ключа.	Просмотр свойств внешнего ключа
Описывает, как отключить ограничения внешнего ключа для репликации.	Отключение ограничений внешнего ключа для репликации
Описывает, как отключить ограничения внешнего ключа на время выполнения инструкций INSERT и UPDATE.	Отключение ограничений внешнего ключа для инструкций INSERT и UPDATE

Добавление и изменение первичного ключа таблицы в Access

Первичный ключ — это поле или набор полей со значениями, которые являются уникальными для всей таблицы. Значения ключа могут использоваться для обозначения всех записей, при этом каждая запись имеет отдельное значение ключа. Каждая таблица может содержать только один первичный ключ. Access может автоматически создавать поле первичного ключа при создании таблицы. Вы также можете самостоятельно указать поля, которые нужно использовать в качестве первичного ключа. В этой статье объясняется, как и зачем использовать первичные ключи.

Чтобы задать первичный ключ таблицы, откройте таблицу в режиме конструктора. Выберите нужное поле (или поля), а затем на ленте щелкните Ключевое поле.

Примечание: Эта статья относится только к классическим базам данных Access. В веб-приложениях Access и веб-базах данных первичный ключ для новых таблиц назначается автоматически. Несмотря на то что автоматические первичные ключи можно менять, делать это не рекомендуется.

В этой статье

• Общие сведения о первичных ключах в Access
• Определение первичного ключа в Access с помощью имеющихся полей
• Удаление первичного ключа
• Изменение первичного ключа в Access
• Дополнительные сведения

Общие сведения о первичных ключах в Access

Используя поля первичных ключей, Access быстро связывает данные из нескольких таблиц и объединяет их понятным образом. Вы можете добавить поля первичных ключей в другие таблицы, чтобы ссылаться на таблицу, которая является источником первичного ключа. В других таблицах поля называются внешними ключами. Например, поле «ИД клиента» в таблице «Клиенты» также может отображаться в таблице «Заказы». В таблице «Клиенты» оно является первичным ключом. В таблице «Заказы» оно называется внешним ключом. Проще говоря, внешний ключ — это первичный ключ другой таблицы. Дополнительные сведения см. в статье Основные сведения о создании баз данных.

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

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

Для первичного ключа автоматически создается индекс, ускоряющий выполнение запросов и операций. Кроме того, приложение Access проверяет наличие и уникальность значений в поле первичного ключа.

При создании таблицы в режиме таблицы Access автоматически создает первичный ключ с именем «Код» и типом данных «Счетчик».

Создание приемлемого первичного ключа

Чтобы правильно выбрать первичный ключ, следует учитывать несколько характеристик.

• Ключ должен однозначно определять каждую строку.
• В нем не должно быть пустых или отсутствующих значений — он всегда содержит значение.
• Ключ крайне редко изменяется (в идеале — никогда).

Если не удается определить приемлемый ключ, создайте для него поле с типом данных «Счетчик». Поле «Счетчик» заполняется автоматически созданными значениями при первом сохранении каждой записи. Таким образом, поле «Счетчик» соответствует всем трем характеристикам приемлемого первичного ключа. Дополнительные сведения о добавлении поля «Счетчик» см. в статье Добавление поля счетчика в качестве первичного ключа.

Поле с типом данных «Счетчик» является хорошим первичным ключом.

Примеры неудачных первичных ключей

Любое поле, не имеющее одной или нескольких характеристик подходящего первичного ключа, не следует выбирать в качестве первичного ключа. Ниже представлено несколько примеров полей, которые не годятся на роль первичного ключа в таблице «Контакты», и пояснения, почему их не следует использовать.

Неподходящий первичный ключ

Может быть не уникальным и может изменяться