Ключ в таблице базы данных не может быть: Реляционные базы данных. Понятие ключа. Виды ключей. Отношения. Главная и подчиненная таблицы

Содержание

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

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

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

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

В этой статье

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

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

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

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

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

2. Внешний ключ

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

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

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

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

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

Ключ должен однозначно определять каждую строку.

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

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

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

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

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

Неподходящий первичный ключ	Причина
Имя	Может быть не уникальным и может изменяться
Телефон	Может изменяться.
Адрес электронной почты	Может изменяться.
Почтовый индекс	Почтовый индекс может соответствовать нескольким контактным данным
Сочетание фактов и цифр	Факты могут изменяться, тем самым усложняя работу. Если фактическая часть повторяется в виде отдельного поля, это может привести к путанице. Например, не следует соединять название города и порядковый номер (например, САМАРА0579), если название города уже указано в отдельном поле.
Номера социального страхования или ИНН	Личные сведения запрещено указывать в государственных учреждениях и некоторых организациях. Некоторые люди не имеют ИНН org/ListItem»> На одного человека может быть зарегистрировано несколько ИНН на протяжении жизни

Составные ключи: использование сочетания нескольких полей в качестве первичного ключа

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

Определение первичного ключа в Access с помощью имеющихся полей

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

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

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

Совет: Если область навигации не отображается, нажмите клавишу F11.
Выберите поле или поля, которые требуется использовать в качестве первичного ключа.

Чтобы выделить одно поле, щелкните область выделения строки нужного поля.

Чтобы при создании составного ключа выделить несколько полей, щелкните область выделения для каждого поля, удерживая нажатой клавишу CTRL.
На вкладке Конструктор в группе Элементы нажмите кнопку Ключевое поле.

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

Удаление первичного ключа в Access

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

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

Перед удалением первичного ключа необходимо убедиться, что он не используется в связях между таблицами. Если вы попытаетесь удалить первичный ключ, являющийся частью одной или нескольких связей, Access предупредит вас, что сначала необходимо удалить связи.
Чтобы удалить связь между таблицами, сделайте следующее:
1. Закройте связанные таблицы, если они открыты. Связь между открытыми таблицами удалить невозможно.
2. На вкладке Работа с базами данных в группе Отношения нажмите кнопку Схема данных.
3. org/ListItem»>
  Выберите Добавить таблицы (Показать таблицу в Access 2013).
4. Щелкните линию связи между таблицами, которую необходимо удалить (выделенная линия становится жирной), а затем нажмите клавишу DEL.
5. На вкладке Конструктор в группе Связи нажмите кнопку Закрыть.
После удаления связей в области навигации щелкните правой кнопкой мыши таблицу, из которой нужно удалить первичный ключ, и в контекстном меню выберите команду Конструктор.

Совет: Если область навигации не отображается, нажмите клавишу F11.
Щелкните область выделения строки для текущего первичного ключа.

Если первичный ключ состоит из одного поля, щелкните область выделения для этого поля.

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

Индикатор ключа будет удален из поля или полей, ранее определенных в качестве первичного ключа.

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

Изменение первичного ключа в Access

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

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

Дополнительные сведения

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

Основные сведения о базах данных
Структура базы данных Access
Создание базы данных Access
Создание таблиц в базе данных

К началу страницы

Реляционные базы данных | Ключи

Последнее обновление: 02. 07.2017

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

Суперключ

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

Например, у нас есть сущность Student, которая представляет данные о пользователях и которая имеет следующие атрибуты:

Какие атрибуты в данном случае могут составлять суперключ:

{FirstName, LastName, Year, Phone}
{FirstName, Year, Phone}
{LastName, Year, Phone}
{FirstName, Phone}
{LastName, Phone}
{Year, Phone}
{Phone}

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

А вот, к примеру, набор {FirstName, LastName, Year} не является суперключом, так как у нас теоретически могут быть как минимум два студента с одинаковыми именем, фамилией и годом рождения.

Потенциальный ключ

Candidate key (потенциальный ключ) — представляет собой минимальный суперключ отношения (таблицы), то есть набор атрибутов, который удовлетворяет ряду условий:

Неприводимость: он не может быть сокращен, он содержит минимально возможный набор атрибутов
Уникальность: он должен иметь уникальные значения вне зависимости от изменения строки
Наличие значения: он не должен иметь значения NULL, то есть он обязательно должен иметь значение.

Возьмем ранее выделенные суперключи и найдем среди них candidate key. Первый пять суперключей не соответствуют первому условию, так как все их можно сократить до суперключа {Phone}:

{FirstName, LastName, Year, Phone}
{FirstName, Year, Phone}
{LastName, Year, Phone}
{FirstName, Phone}
{LastName, Phone}
{Year, Phone}

Суперключ {Phone} соответствует первому и второму условию, так как он имеет уникальное значение (в данном случае все пользователи могут иметь только уникальные телефонные номера). Но соответствует ли он третьему условию? В целом нет, так как теоретически студент может и не иметь телефона. В этом случае атрибут Phone будет иметь значение NULL, то есть значение будет отсутствовать.

В то же время это может зависеть от ситуации. Если в какой-то систему номер телефона является неотъемлемым атрибутом, например, используется для регистрации и входа в систему, то его можно считать потенциальным ключом. Но в данном случае мы рассматриваем общую ситуацию. И для понимания потенциального ключа необходимо отталкиваться от конкретной системы, которую описывает база данных.

И в таком случае суперключи таблицы не содержат потенциального ключа.

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

Первичный ключ (primary key) непосредственно применяется для идентификации строк в таблице. Он должен соответствовать следующим ограничениям:

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

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

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

Если же потенциальные ключи отсутствуют, то для первичного ключа можно добавить к сущности специальный атрибут, который, как правило, называется, Id или имеет форму [Имя_сущности]Id (например, StudentId), либо может иметь другое название. И обычно данный атрибут принимает целочисленное значение, начиная с 1.

Если же у нас есть несколько потенциальных ключей, то те потенциальные ключи, которые не составляют первичный ключ, являются альтернативными ключами (alternative key).

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

Name (имя пользователя)
Email (электронный адрес)
Password (пароль)
Phone (телефонный номер)

В данном случае атрибуты Email и Phone являются потенциальными ключами, они обязательны в рамках рассматриваемой системы и в принципе уникальны. И теоретически, мы можем использовать один из этих атрибутов в качестве первичного ключа, тогда второй будет альтернативным ключом. Однако опять же поскольку теоретически значения обоих атрибутов могут меняться, то лучше все таки определить дополнительный атрибут специально под первичный ключ.

НазадСодержаниеВперед

Ограничения первичного и внешнего ключа — SQL Server

Статья
16. 08.2022
9 минут на чтение

Применимо к: SQL Server 2016 (13.x) и более поздние версии База данных SQL Azure Управляемый экземпляр Azure SQL

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

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

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

Когда вы указываете ограничение первичного ключа для таблицы, Компонент Database Engine обеспечивает уникальность данных, автоматически создавая уникальный индекс для столбцов первичного ключа. Этот индекс также обеспечивает быстрый доступ к данным, когда в запросах используется первичный ключ. Если ограничение первичного ключа определено более чем для одного столбца, значения могут дублироваться в одном столбце, но каждая комбинация значений из всех столбцов в определении ограничения первичного ключа должна быть уникальной.

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

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

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

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

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

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

Более 253 ссылок на внешние ключи поддерживаются только для операций DELETE DML. Операции UPDATE и MERGE не поддерживаются.
Таблица со ссылкой внешнего ключа на себя по-прежнему ограничена 253 ссылками внешнего ключа.
Более 253 ссылок на внешние ключи в настоящее время недоступны для индексов columnstore, таблиц, оптимизированных для памяти, базы данных Stretch или секционированных таблиц внешних ключей.
Важно
База данных Stretch устарела в предварительной версии SQL Server 2022 (16.x). Эта функция будет удалена в будущей версии Microsoft SQL Server. Избегайте использования этой функции в новых разработках и планируйте модифицировать приложения, которые в настоящее время используют эту функцию.

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

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

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

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

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

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

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

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

НЕТ ДЕЙСТВИЙ Компонент Database Engine выдает ошибку, и действие удаления или обновления строки в родительской таблице откатывается.

CASCADE Соответствующие строки обновляются или удаляются в ссылочной таблице, когда эта строка обновляется или удаляется в родительской таблице. CASCADE не может быть указан, если 9Столбец 0015 timestamp является частью либо внешнего ключа, либо ключа, на который указывает ссылка. 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 могут быть объединены в таблицах, которые имеют ссылочные отношения друг с другом. Если компонент Database Engine обнаруживает NO ACTION, он останавливается и откатывает связанные действия CASCADE, SET NULL и SET DEFAULT. Когда оператор DELETE вызывает комбинацию действий CASCADE, SET NULL, SET DEFAULT и NO ACTION, все действия CASCADE, SET NULL и SET DEFAULT применяются до того, как компонент Database Engine проверит наличие NO ACTION.

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

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

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

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

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

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

`sqlite - Может ли таблица базы данных не иметь первичного ключа?`

спросил 4 года 11 месяцев назад

Изменено 2 года, 1 месяц назад

Просмотрено 68 тысяч раз

Может ли таблица базы данных не иметь первичного ключа? SQLite позволяет вам определить таблицу без первичного ключа, поэтому не может быть аномалии вставки.

первичный ключ
sqlite

2

Можно ли создать таблицу базы данных без первичного ключа? Ну, вы только что сказали, что можете в SQLite. И я считаю, что это верно почти для каждой (если не для каждой) основной платформы СУБД.

Следует ли создать таблицу базы данных без первичного ключа? №

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

Правда, без первичного ключа (или какой-то уникальный ключ ), у вас не будет аномалии вставки, если вы будете вставлять одни и те же данные несколько раз.

То, что вы делаете , представляет собой таблицу пользователей с 300 отдельными записями для пользователя с именем "bob", многие из которых имеют разные значения в других столбцах. И, если вы попытались соединить строки в какой-либо другой таблице с пользователем без отношения первичного/внешнего ключа - каждая строка в сообщении , помеченная как send_by "bob", связана с каждым из этих 300 пользователей записей.