Sql первичный ключ: SQL — Primary Key (Первичный ключ)

19) Первичный ключ против уникального ключа

Что такое первичный ключ?

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

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

В этом уроке вы узнаете:

Что такое уникальный ключ?

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

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

Зачем использовать первичный ключ?

Вот важные причины для использования первичного ключа:

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

Зачем использовать уникальный ключ?

Вот важные причины для использования уникального ключа:

• Цель уникального ключа — убедиться, что информация в столбце для каждой записи таблицы уникальна.
• Когда вы позволяете пользователю ввести нулевое значение.
• Уникальный ключ используется, потому что он создает некластеризованный индекс по умолчанию.
• Уникальный ключ может быть использован, когда вам нужно сохранить нулевые значения в столбце.
• Когда одно или несколько полей / столбцов таблицы, однозначно идентифицируют запись в таблице базы данных.

Особенности первичного ключа

Вот важные особенности первичного ключа:

• Первичный ключ реализует целостность объекта таблицы.
• Вы можете сохранить только один основной элемент в таблице.
• Первичный ключ содержит один или несколько столбцов таблицы.
• Столбцы определены как не нулевые.

Особенности Уникального ключа

Вот важные особенности уникального ключа:

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

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

В следующем примере описано, что существует таблица с именем student. Он содержит пять атрибутов: 1) StudID, 2) Roll No, 3) Имя, 4) Фамилия и 5) Электронная почта.

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

Пример первичного ключа

Пример создания уникального ключа

Рассмотрим ту же таблицу учеников с атрибутами: 1) StudID, 2) Roll No, 3) Имя, 4) Фамилия и 5) Электронная почта.

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

Пример уникального ключа

Разница между Первичным ключом и Уникальным ключом

Вот важные различия между первичным ключом и уникальным ключом:

CREATE TABLE Employee
(
ID int PRIMARY KEY, 
Name varchar(255), 
City varchar(150)
)

CREATE TABLE Employee
(
ID int UNIQUE.
Name varchar(255) NOT NULL. City varchar(150)
)

Что лучше?

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

ОСНОВНЫЕ РАЗЛИЧИЯ:

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

9) Ключи СУБД — CoderLessons.com

Какие ключи?

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

Пример:

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

В этом уроке вы узнаете:

Зачем нам нужен ключ?

Вот причины использования ключей в системе СУБД.

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

Различные ключи в системе управления базами данных

СУБД имеет следующие семь типов ключей, каждый из которых имеет свои различные функции:

• Супер Ключ
• Основной ключ
• Ключ-кандидат
• Альтернативный ключ
• Внешний ключ
• Составной ключ
• Композитный ключ
• Суррогатный ключ

Что такое супер ключ?

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

Пример:

В приведенном выше примере имена EmpSSN и EmpNum являются суперключами.

Что такое первичный ключ?

PRIMARY KEY — это столбец или группа столбцов в таблице, которые уникально идентифицируют каждую строку в этой таблице. Первичный ключ не может быть дубликатом, то есть одно и то же значение не может появляться в таблице более одного раза. Таблица не может иметь более одного первичного ключа.

Правила определения первичного ключа:

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

Пример:

В следующем примере <code> StudID </ code> является первичным ключом.

Что такое альтернативный ключ?

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

Пример:

В этой таблице StudID, Roll No, Email могут стать первичным ключом. Но поскольку StudID является первичным ключом, Roll No, Email становится альтернативным ключом.

Что такое ключ-кандидат?

CANDIDATE KEY — это набор атрибутов, которые однозначно идентифицируют кортежи в таблице. Ключ-кандидат — это супер-ключ без повторяющихся атрибутов. Первичный ключ должен быть выбран из возможных ключей. В каждой таблице должен быть хотя бы один ключ-кандидат. Таблица может иметь несколько ключей-кандидатов, но только один первичный ключ.

Свойства ключа-кандидата:

• Он должен содержать уникальные значения
• Ключ-кандидат может иметь несколько атрибутов
• Не должен содержать нулевые значения
• Он должен содержать минимальные поля для обеспечения уникальности
• Уникальная идентификация каждой записи в таблице

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

Что такое внешний ключ?

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

Пример:

В этом примере у нас есть два стола, учить и отдел в школе. Тем не менее, нет способа узнать, какой поиск работает в каком отделе.

В этой таблице, добавив внешний ключ в Deptcode к имени учителя, мы можем создать связь между двумя таблицами.

Эта концепция также известна как ссылочная целостность.

Что такое составной ключ?

КЛАВИША СОЕДИНЕНИЯ имеет два или более атрибута, которые позволяют однозначно распознавать конкретную запись. Возможно, что каждый столбец не может быть уникальным сам по себе в базе данных. Однако при объединении с другим столбцом или столбцами комбинация составных ключей становится уникальной. Целью составного ключа является уникальная идентификация каждой записи в таблице.

Пример:

В этом примере OrderNo и ProductID не могут быть первичным ключом, поскольку они не уникально идентифицируют запись. Однако можно использовать составной ключ из идентификатора заказа и идентификатора продукта, поскольку он однозначно идентифицирует каждую запись.

Что такое композитный ключ?

КОМПОЗИЦИОННЫЙ КЛЮЧ — это комбинация двух или более столбцов, которые однозначно идентифицируют строки в таблице. Комбинация столбцов гарантирует уникальность, хотя индивидуальная уникальность не гарантируется. Следовательно, они объединены, чтобы однозначно идентифицировать записи в таблице.

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

Что такое суррогатный ключ?

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

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

Суррогатные ключи разрешены, когда

• Ни одно свойство не имеет параметра первичного ключа.
• В таблице, когда первичный ключ слишком большой или сложный.

Разница между первичным и внешним ключом

Резюме

• Ключ СУБД — это атрибут или набор атрибутов, который помогает вам идентифицировать строку (кортеж) в отношении (таблице)
• Ключи СУБД позволяют установить связь и идентифицировать связь между таблицами
• Семь типов ключей СУБД: супер, первичный, кандидатный, альтернативный, внешний, составной, составной и суррогатный ключ.
• Суперключ — это группа из одного или нескольких ключей, которая идентифицирует строки в таблице.
• Столбец или группа столбцов в таблице, которая помогает нам однозначно идентифицировать каждую строку в этой таблице, называется первичным ключом.
• Все ключи, которые не являются первичными ключами, называются альтернативными ключами.
• Супер ключ без повторяющегося атрибута называется ключом-кандидатом
• Составной ключ — это ключ, который имеет много полей, которые позволяют однозначно распознать конкретную запись
• Ключ, имеющий несколько атрибутов для уникальной идентификации строк в таблице, называется составным ключом.
• Искусственный ключ, предназначенный для уникальной идентификации каждой записи, называется суррогатным ключом.
• Первичный ключ никогда не принимает нулевые значения, в то время как внешний ключ может принимать несколько нулевых значений.

Первичный ключ — Википедия

Перви́чный ключ (англ. primary key) — в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию).

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

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

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

Исторически термин «первичный ключ» появился и стал использоваться существенно ранее термина «потенциальный ключ». Вследствие этого множество определений в реляционной теории были изначально сформулированы с упоминанием первичного (а не потенциального) ключа, например, определения нормальных форм. Также термин «первичный ключ» вошёл в формулировку 12 правил Кодда как основной способ адресации любого значения отношения (таблицы) наряду с именем отношения (таблицы) и именем атрибута (столбца).

Простые и составные ключиПравить

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

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

Естественные и суррогатные ключиПравить

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

получить первичный ключ таблицы с помощью sql query [duplicate]

Это должно перечислить все ограничения, и в конце вы можете поместить свои фильтры

/* CAST IS DONE , SO THAT OUTPUT INTEXT FILE REMAINS WITH SCREEN LIMIT*/
WITH   ALL_KEYS_IN_TABLE (CONSTRAINT_NAME,CONSTRAINT_TYPE,PARENT_TABLE_NAME,PARENT_COL_NAME,PARENT_COL_NAME_DATA_TYPE,REFERENCE_TABLE_NAME,REFERENCE_COL_NAME) 
AS
(
SELECT  CONSTRAINT_NAME= CAST (PKnUKEY.name AS VARCHAR(30)) ,
        CONSTRAINT_TYPE=CAST (PKnUKEY.type_desc AS VARCHAR(30)) ,
        PARENT_TABLE_NAME=CAST (PKnUTable.name AS VARCHAR(30)) ,
        PARENT_COL_NAME=CAST ( PKnUKEYCol.name AS VARCHAR(30)) ,
        PARENT_COL_NAME_DATA_TYPE=  oParentColDtl.DATA_TYPE,        
        REFERENCE_TABLE_NAME='' ,
        REFERENCE_COL_NAME='' 

FROM sys.key_constraints as PKnUKEY
    INNER JOIN sys.tables as PKnUTable
            ON PKnUTable.object_id = PKnUKEY.parent_object_id
    INNER JOIN sys.index_columns as PKnUColIdx
            ON PKnUColIdx.object_id = PKnUTable.object_id
            AND PKnUColIdx.index_id = PKnUKEY.unique_index_id
    INNER JOIN sys.columns as PKnUKEYCol
            ON PKnUKEYCol.object_id = PKnUTable.object_id
            AND PKnUKEYCol.column_id = PKnUColIdx.column_id
     INNER JOIN INFORMATION_SCHEMA.COLUMNS oParentColDtl
            ON oParentColDtl.TABLE_NAME=PKnUTable.name
            AND oParentColDtl.COLUMN_NAME=PKnUKEYCol.name
UNION ALL
SELECT  CONSTRAINT_NAME= CAST (oConstraint.name AS VARCHAR(30)) ,
        CONSTRAINT_TYPE='FK',
        PARENT_TABLE_NAME=CAST (oParent.name AS VARCHAR(30)) ,
        PARENT_COL_NAME=CAST ( oParentCol.name AS VARCHAR(30)) ,
        PARENT_COL_NAME_DATA_TYPE= oParentColDtl.DATA_TYPE,     
        REFERENCE_TABLE_NAME=CAST ( oReference.name AS VARCHAR(30)) ,
        REFERENCE_COL_NAME=CAST (oReferenceCol.name AS VARCHAR(30)) 
FROM sys.foreign_key_columns FKC
    INNER JOIN sys.sysobjects oConstraint
            ON FKC.constraint_object_id=oConstraint.id 
    INNER JOIN sys.sysobjects oParent
            ON FKC.parent_object_id=oParent.id
    INNER JOIN sys.all_columns oParentCol
            ON FKC.parent_object_id=oParentCol.object_id /* ID of the object to which this column belongs.*/
            AND FKC.parent_column_id=oParentCol.column_id/* ID of the column. Is unique within the object.Column IDs might not be sequential.*/
    INNER JOIN sys.sysobjects oReference
            ON FKC.referenced_object_id=oReference.id
    INNER JOIN INFORMATION_SCHEMA.COLUMNS oParentColDtl
            ON oParentColDtl.TABLE_NAME=oParent.name
            AND oParentColDtl.COLUMN_NAME=oParentCol.name
    INNER JOIN sys.all_columns oReferenceCol
            ON FKC.referenced_object_id=oReferenceCol.object_id /* ID of the object to which this column belongs.*/
            AND FKC.referenced_column_id=oReferenceCol.column_id/* ID of the column. Is unique within the object.Column IDs might not be sequential.*/

)

select * from   ALL_KEYS_IN_TABLE
where   
    PARENT_TABLE_NAME  in ('YOUR_TABLE_NAME') 
    or REFERENCE_TABLE_NAME  in ('YOUR_TABLE_NAME')
ORDER BY PARENT_TABLE_NAME,CONSTRAINT_NAME;

для справки, пожалуйста, прочитайте через -http://blogs.msdn.com/b/sqltips/archive/2005/09/16/469136.aspx

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

Ключи

Последнее обновление: 02.07.2017

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

Суперключ

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

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

• FirstName (имя)

• LastName (фамилия)

• Year (год рождения)

• Phone (номер телефона)

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

• {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 являются потенциальными ключами, они обязательны в рамках рассматриваемой системы и в принципе уникальны.
И теоретически, мы можем использовать один из этих атрибутов в качестве первичного ключа, тогда второй будет альтернативным ключом.
Однако опять же поскольку теоретически значения обоих атрибутов могут меняться, то лучше все таки определить дополнительный атрибут специально под первичный ключ.

первичные, уникальные, родительские и внешние ключи

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

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

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

Уникальный ключ

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

• уникальных ключей для одной таблицы может быть несколько (вопросик на засыпку для тех, кто прочитал статью про нормализацию: правила какой нормальной формы при этом будут нарушены? 😉
• уникальные ключи могут иметь значения NULL, при этом если имеется несколько строк со значениями уникального ключа NULL, такие строки согласно стандарту SQL 92 считаются различными (уникальными).

Внешний ключ

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

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

И самое главное. Все значения внешнего ключа должны совпадать с каким-либо из значений родительского ключа. (Заметим в скобках насчет совпадения / несовпадения: нюансы возникают, когда в значениях столбцов вторичного ключа встречается NULL. Давайте пока в эти нюансы вдаваться не будем). Появление значений внешнего ключа, для которых нет соответствующих значений родительского ключа, недопустимо. Вот тут-то мы плавно переходим к понятию ссылочной целостности.

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

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

Более интересные моменты возникают, когда мы удаляем или изменяем строки родительской таблицы. Как при этом не допустить появления \»болтающихся в воздухе\» строк дочерней таблицы? Для этого существуют правила ссылочной целостности ON UPDATE и ON DELETE, которые, по стандарту SQL 92, могут содержать следующие инструкции:

• CASCADE — обеспечивает автоматическое выполнение в дочерней таблице тех же изменений, которые были сделаны в родительском ключе. Если родительский ключ был изменен — ON UPDATE CASCADE обеспечит точно такие же изменения внешнего ключа в дочерней таблице. Если строка родительской таблицы была удалена, ON DELETE CASCADE обеспечит удаление всех соответствующих строк дочерней таблицы.
• SET NULL — при удалении строки родительской таблицы ON DELETE SET NULL установит значение NULL во всех столбцах вторичного ключа в соответствующих строках дочерней таблицы. При изменении родительского ключа ON UPDATE SET NULL установит значение NULL в соответствующих столбцах соответствующих строк (о как:) дочерней таблицы.
• SET DEFAULT — работает аналогично SET NULL, только записывает в соответствующие ячейки не NULL, а значения, установленные по умолчанию.
• NO ACTION (установлено по умолчанию) — при изменении родительского ключа никаких действий с внешним ключом в дочерней таблице не производится. Но если изменение значений родительского ключа приводит к нарушению ссылочной целосности (т.е. к появлению «висящих в воздухе» строк дочерней таблицы), то СУБД не даст произвести такие изменения родительской таблицы.

Ну а сейчас — от общего к частному.

Ключи и ссылочная целостность в MySQL и Oracle

Oracle поддерживает первичные, уникальные, внешние ключи в полном объеме. Oracle поддерживает следующие правила ссылочной целостности:

• NO ACTION (устанавливается по умолчанию) в более жестком, чем по стандарту SQL 92, варианте: запрещается изменение и удаление строк родительской таблицы, для которых имеются связанные строки в дочерних таблицах.
• ON DELETE CASCADE.

Более сложные правила ссылочной целостности в Oracle можно реализовать через механизм триггеров.

MySQL версии 4.1 (последняя на момент написания статьи стабильная версия) позволяет в командах CREATE / ALTER TABLE задавать фразы REFERENCES / FOREIGN KEY, но в работе никак их не учитывает и реально внешние ключи не создает. Соответственно правила ссылочной целостности, реализуемые через внешние ключи, в MySQL не поддерживаются. И все заботы по обеспечению целостности и непротиворечивости информации в базе MySQL ложатся на плечи разработчиков клиентских приложений.

Разработчики MySQL обещают реализовать работу с внешними ключами и поддержание ссылочной целостности в версии 5.0. Что ж, когда версия MySQL 5.0 станет стабильной — посмотрим, что там в итоге получится. Очень, очень хотелось бы, чтобы MySQL поддерживала ссылочную целостность (без ущерба для производительности:).

Выучить SQL: первичный ключ

Если вы уже работали с базами данных, то вряд ли могли пропустить термин — первичный ключ (PK). И если вы читаете эту серию статей и используете ее для изучения баз данных, то эта статья должна дать вам хорошее представление о том, что такое PK на самом деле. Тем не менее, если вы эксперт по базам данных, возможно, вы найдете что-то новое или просто освежите свои знания. Итак, расслабьтесь, расслабьтесь и давайте погрузимся в ПК.

Что такое первичный ключ (PK)?

Мы буквально окружены ПК в мире баз данных.Но в основном мы принимаем их как должное. Перед примерами давайте
пойти с упрощенным определением ПК:

«Первичный ключ — это значение, уникальное для каждой записи в таблице».

И правило — «Каждая таблица в базе данных должна иметь определенный PK».

Структура нашей базы данных

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

Теперь мы готовы перейти к примерам первичных ключей из реальной жизни:

• Каждая страна в мире имеет уникальное название и код (ISO, ICAO, IOC, E. 164 или любой другой). Оба являются ПК в
  в реальной жизни (а также могут быть PK или альтернативные ключи / уникальные значения в базе данных)
• У каждого сотрудника есть уникальный личный номер, балансовая единица и т. Д.
• Каждый звонок имеет уникальную комбинацию того, кто кому звонил и в какой момент. (Обратите внимание, что нам нужны все 3
  из них — всего двух будет недостаточно. Например. агент колл-центра может звонить одному и тому же клиенту много раз)

Мы закончим эту часть более подробным определением.

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

Например, если вы знаете название страны, вы легко найдете строку с этим названием и получите доступ к
оставшиеся значения, относящиеся к этой стране — население, статистические данные и т. д.

Какова цель первичного ключа (PK)?

Без PK базы данных не работали бы так, как они работают сейчас, или, если быть точным, не работали бы вообще.

Давайте посмотрим, что есть в нашей базе данных. Чтобы развернуть «дерево», нажмите на знак «+» рядом с «Базы данных»,
имя базы данных («our_first_database»), имена таблиц («dbo.city» и «dbo.country») и «Ключи»:

Вы можете легко заметить, что в обеих таблицах есть PK («city_pk», «country_pk»), а в таблице «dbo.country» есть
альтернативные ключи / уникальные значения («country_ak_1», «country_ak_2», «country_ak_3»).Ключ city_country — это
внешний ключ, и мы обсудим это позже. Чтобы прояснить, откуда все это взялось, напомним
команды, используемые для создания этих двух таблиц:

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

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

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

   .

2. Значения, не имеющие никакого значения в реальном мире (обычно первичные ключи). Работает в том же
   как и в предыдущем случае, но мы будем использовать числовое значение из столбца id для доступа к
   определенная страна

   Думаю, вы видите проблему в этом подходе.Поскольку PK были созданы системой, мы не можем знать, какое значение id
   должны быть присвоены какой стране — они будут назначены в том же порядке, в котором страны были вставлены в таблицу,
   и это в значительной степени «случайный» порядок

Тем не менее, во втором подходе есть некоторая магия, потому что в некоторых случаях система знает, что такое значение PK. Так,
цель ПК — использовать его, когда мы получаем доступ к данным и когда мы (или система) знаем это значение.Мы объясним, как система узнает это значение, в следующей статье при описании внешних ключей.

Первичный ключ VS. UNIQUE (альтернативные ключи)

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

• Каждая таблица в базе данных должна иметь PK .Это будет не только
  улучшить общую производительность базы данных, но также важно для того, чтобы данные были связаны и согласованы
• В каждую таблицу я добавлю столбец с именем id . Используется как столбец PK, тип
  целое число без знака, с IDENTITY, равным (1,1) . Таким образом, СУБД автоматически сгенерирует PK
  значения по мере добавления строк. Использование целых чисел в качестве PK также значительно улучшает производительность (индекс создается поверх
  этот атрибут автоматически! — индексы рассматриваются в отдельной статье)
• Все атрибуты , кроме PK, , которые содержат уникальные значения, должны быть определены как
  UNIQUE (альтернативные ключи).Это свойство может быть определено для одного атрибута или для комбинации нескольких атрибутов. Это предотвратит вставку нежелательных повторяющихся значений.
  • Например. если для country_name не определено UNIQUE, и мы дважды вставляем страну с таким же названием,
    у нас будет 2 записи с разными идентификаторами и одинаковым country_name. СУБД будет рассматривать их как 2
    различные страны. Указание альтернативного ключа / UNIQUE предотвращает это.Давайте возьмем
    посмотрите на пример. В нашей базе данных уже есть страна с названием «Deutschland».

Поскольку мы определили правила UNIQUE для 3 столбцов, все 3 из них будут препятствовать этому оператору Insert, и это желаемое поведение. Мы определили правила, и система заботится о том, соответствуют ли данные, которые мы хотим вставить, этим правилам.

Заключение

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

Содержание

Эмиль — профессионал в области баз данных с более чем 10-летним опытом работы во всем, что связано с базами данных.В течение многих лет он работал в сфере информационных технологий и финансов, а сейчас работает фрилансером.

Его прошлые и настоящие занятия варьируются от дизайна и программирования баз данных до обучения, консультирования и написания статей о базах данных. Также не забывайте, BI, создание алгоритмов, шахматы, филателия, 2 собаки, 2 кошки, 1 жена, 1 ребенок …

Вы можете найти его в LinkedIn

Просмотреть все сообщения Эмиля Drkusic

Последние сообщения Эмиля Drkusic (увидеть все)

Первичный ключ и отношение внешнего ключа SQL Server

Вернуться к: Учебное пособие по SQL Server для начинающих и профессионалов

Отношения первичного и внешнего ключей между несколькими таблицами в SQL Server

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

Как установить связь первичного и внешнего ключей между более чем двумя таблицами в SQL Server:

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

Создание таблицы клиентов

 CREATE TABLE Клиент
(
    Cid INT ПЕРВИЧНЫЙ КЛЮЧ,
    Cname VARCHAR (40),
    Cmobno СИМВОЛ (10)
)
 

Добавление значения

 ВСТАВИТЬ В ЗНАЧЕНИЯ клиента (1, 'AA', '9853977973')
ВСТАВИТЬ ЗНАЧЕНИЯ клиента (2, 'BB', '8895558077')
ВСТАВИТЬ ЗНАЧЕНИЯ клиента (3, 'CC', '7021801173')
 

ВЫБРАТЬ * ОТ клиента

Затем создайте таблицу 2 ^и с именем «Продукты», используя ограничение первичного ключа, и вставьте некоторые значения в таблицу «Продукты».

Создание таблицы товаров

 CREATE TABLE Продукты
(
    Pcode INT ПЕРВИЧНЫЙ КЛЮЧ,
    Pname VARCHAR (20),
    Цена ДЕНЬГИ
)
 

Добавление значения

 ВСТАВИТЬ ЗНАЧЕНИЯ продуктов (10, 'C', 500)
ВСТАВИТЬ ЗНАЧЕНИЯ продуктов (20, 'C ++', 1000)
ВСТАВИТЬ В ЗНАЧЕНИЯ продуктов (30, '. NET', 3500)
ВСТАВИТЬ ЗНАЧЕНИЯ продуктов (40, 'SQL', 1800)
 

ВЫБРАТЬ * ИЗ продуктов

Теперь создайте таблицу 3 ^rd с именем «Заказы», ​​используя ссылки на внешние ключи и некоторые ссылочные значения в таблице ORDERS.

Создание таблицы заказов

 CREATE TABLE Заказы
(
    Odid INT ПЕРВИЧНЫЙ КЛЮЧ,
    Ordate DATE,
    Количество INT,
    Cid INT ИНОСТРАННЫЕ КЛЮЧЕВЫЕ ССЫЛКИ Клиент (Cid),
    Pcode INT ИНОСТРАННЫЕ КЛЮЧЕВЫЕ ССЫЛКИ Продукты (Pcode)
)
 

Добавление значения

 ВСТАВИТЬ В ЗНАЧЕНИЯ заказов (101, '2017/12/20', 9,1,10)
ВСТАВИТЬ ЗНАЧЕНИЯ заказов (102, '2017/12/20', 10,2,10)
ВСТАВИТЬ В ЗНАЧЕНИЯ заказов (103, '2017/12/21', 6,3,20)
ВСТАВИТЬ ЗНАЧЕНИЯ заказов (104, '2017/12/22', 11,1,40)
ВСТАВИТЬ ЗНАЧЕНИЯ заказов (105, '2017/12/23', 8,1,30)
 

ВЫБРАТЬ * ИЗ Заказы

Как добавить ограничение к существующей таблице?

Синтаксис:

ALTER TABLE

Случай1: Добавление ограничения первичного ключа к существующему столбцу в таблице.

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

Пример: Сначала создайте следующую таблицу без ограничения

CREATE TABLE EMP (EMPID INT, ENAME VARCHAR (30), SALARY MONEY)

Перед добавлением ограничения первичного ключа нам нужно сделать его НЕ NULL, как показано ниже

ALTER TABLE EMP ALTER COLUMN EMPID INT NOT NULL

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

ALTER TABLE EMP ADD CONSTRAINT X PRIMARY KEY (EMPID)

Теперь столбец EMPID содержит первичный ключ.

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

Случай2: Добавление уникального ограничения к существующему столбцу в таблице.

ALTER TABLE EMP ADD CONSTRAINT Y UNIQUE (ENAME)

Case3: Добавление ограничения CHECK к существующему столбцу.

ИЗМЕНИТЬ ТАБЛИЦУ EMP ДОБАВИТЬ ОГРАНИЧЕНИЕ z ПРОВЕРИТЬ (ЗАРПЛАТА> 8000)

Case4: Добавление ограничения FOREIGN KEY к существующему столбцу.

Давайте создадим еще одну таблицу с именем DEP, как показано ниже

СОЗДАТЬ ТАБЛИЦУ DEP (DNO INT, DNAME VARCHAR (30), EID INT)

Теперь мы можем сделать столбец EID таблицы DEP как FOREIGN KEY, поскольку столбец EID является первичным ключом в столбце EMP.

ИЗМЕНИТЬ ТАБЛИЦУ DEP ДОБАВИТЬ ОГРАНИЧЕНИЕ Q ИНОСТРАННЫЙ КЛЮЧ (EID) ССЫЛКИ EMP (EMPID)

Как удалить ограничения из существующей таблицы?

Синтаксис для удаления:

ALTER TABLE DROP CONSTRAINT

Пример:

ALTER TABLE EMP DROP CONSTRAINT Y

ALTER TABLE EMP DROP CONSTRAINT Z

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

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

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

sql kullanm nasldr

ПЕРВИЧНЫЙ КЛЮЧ SQL Kullanm

ПЕРВИЧНЫЙ КЛЮЧ ile tablomuzdaki ilgili alanda benzersiz kaytlarn tutulmasn
istediimiz durumlarda kullanlr.Япсал оларак УНИКАЛЬНЫЙ или картрлабилир.
Aradaki farklar sralayacak olursak:

— Birden fazla alan tek bir ПЕРВИЧНЫЙ КЛЮЧ ile tanmlanabilir. ПЕРВИЧНЫЙ КЛЮЧ Ancak
тявкает таблода sadece bir tane olabilir. UNIQUE yaps bir tabloda birden
fazla olabilir.
— ПЕРВИЧНЫЙ КЛЮЧ yaps ile bo kaytlara izin verilmez. УНИКАЛЬНЫЙ yapsnda бо
кайтлара изи н верилир.
— ПЕРВИЧНЫЙ КЛЮЧ yaps ile tablo zerinde bir index tanm oluturulur her kaydn
бензерсиз бир танм яплр.Bylece kullandnz uygulama gelitirme
ortamnda (r: .NET) табло zerinde daha etkin sonular elde edilebilir. УНИКАЛЬНЫЙ
yapsnda ise alandaki deerlerin benzersiz olup olmadna baklr. Birden
fazla alanda UNIQUE yapldnda bunlar bir index adyla tanmlanma
salaabilir ancak bu sadece bir tanmladr.

ПЕРВИЧНЫЙ КЛЮЧ Kullanm Biimi

SQL Server / Oracle / MS Acess ortamlarnda sadece bir alanda kullanm biimine
рнек:

ПЕРВИЧНЫЙ КЛЮЧ kriterini sadece bir alana vereceksek nasl kullanlaca gsterilmitir.

MySQL ortamnda sadece bir alanda kullanm biimine rnek:

Grld gibi MySQL veritabannda ilem yapacaksanz PRIMARY KEY ifadesini
sonradan belirtmeniz gerekmektedir.

MySQL / SQL Server / Oracle / MS Access ortamlarnda birden fazla alanda
kullanm biimine rnek:

Burada grlecei zere birden fazla alan PRIMARY KEY yaps iine alnyor.ОГРАНИЧЕНИЕ
ifadesi ile bu ileme bir tanm giriliyor. Aslnda bu tanm bizim tablomuzun
index alann oluturmaktadr. ndexleme sayesinde tablomuzdaki verilerin
БТЛ Даха салам олуркен арамаларда да даха зл сонуляр Элде эдериз.
Ayrca kullandnz uygulama gelitirme ortamlarnda (r .Net) табло зеринде
Даха эткин кулланм imkannz olacaktr. ГЛАВНЫЙ КЛЮЧ ifadesinden sonra ise ilgili alanlar virgl ile ayrarak yazarz.

Yuakrdaki rnekler hep yeni bir veritaban oluturuken kullanlan
rneklerdir.Ancak var olan bir veritabannda bir alan ПЕРВИЧНЫЙ КЛЮЧ yapmak istersek
ALTER yapsn kullanmamz gerekir.

MySQL / SQL Server / Oracle / MS Access ortamlarnda bir alanda kullanm
biimine rnek:

MySQL / SQL Server / Oracle / MS Access ortamlarnda birden fazla alanda
kullanm biimine rnek:

Burada dikkat edilecek nokta; ALTER ile sonradan bir alana PRIMARY KEY
kriteri tanmlanrken ilgili alanda veya alanlarda NULL яни бо кайт
olmamaldr.

Eer PRIMARY KEY olarak kriterlendirilmi alan normale evirmek istersek DROP
ifadesini kullanmamz gerekir.

SQL Server / Oracle / MS Access ortamlarnda ПЕРВИЧНЫЙ КЛЮЧ yapsn kaldrmak:

Burada dikkat edilmesi gereken nokta eer oklu alanda ПЕРВИЧНЫЙ КЛЮЧ ilemi
yaptysak, CONSTRAINT ifadesinden sonra tablomuzdaki alan ad deil ,
oluturduumuz index ad yazlmaldr.Eer tek bir alanda oluturduysak o zaman
ОГРАНИЧЕНИЕ ifadesinden sonra sadece alana adn yazabiliriz.

MySQL ortamlarnda ПЕРВИЧНЫЙ КЛЮЧ yapsn kaldrmak:

MySQL yapsndan silerken tek fark direk olarak ПЕРВИЧНЫЙ КЛЮЧ ifadesi
kullanlr.

ПЕРВИЧНЫЙ КЛЮЧ

SQL 约束 |菜鸟 教程

ПЕРВИЧНЫЙ КЛЮЧ SQL 约束

ПЕРВИЧНЫЙ КЛЮЧ 约束 唯一 标识 数据库 表 中 的 每条 记录。

主 键 必须 包含 唯一 的 值。

主 键 列 不能 包含 NULL 值。

每个 表 都 应该 有 一个 主 键 ， 并且 每个 表 只能 有 一个 主 键。

CREATE TABLE 的 SQL PRIMARY KEY 约束

下面 的 SQL 在 «Persons» 表 创建 时 在 «P_Id» 列 上 创建 PRIMARY KEY 约束 ：

MySQL ：

СОЗДАТЬ ТАБЛИЦУ Персон
(
P_Id int NOT NULL,
LastName varchar (255) NOT NULL,
Имя varchar (255),
Адрес varchar (255),
Город варчар (255),
ПЕРВИЧНЫЙ КЛЮЧ (P_Id)
)

SQL Server / Oracle / MS Access ：

СОЗДАТЬ ТАБЛИЦУ Персон
(
P_Id int NOT NULL ПЕРВИЧНЫЙ КЛЮЧ,
LastName varchar (255) NOT NULL,
Имя varchar (255),
Адрес varchar (255),
Городской варчар (255)
)

PRIMARY KEY 并 定义 多个 的 PRIMARY KEY ， 请 使用 的 SQL 语法 ：

MySQL / SQL Server / Oracle / MS Access ：

СОЗДАТЬ ТАБЛИЦУ Персон
(
P_Id int NOT NULL,
LastName varchar (255) NOT NULL,
Имя varchar (255),
Адрес varchar (255),
Город варчар (255),
ОГРАНИЧЕНИЕ pk_PersonID PRIMARY KEY (P_Id, LastName)
)

注释 ： 在 上面 的 实例 中 ， 只有 一个 主 PRIMARY KEY （pk_PersonID）。 然而 ， pk_PersonID 的 值 是 由 两个 列 （P_Id 和
Фамилия） 组成 的。

ALTER TABLE 的 SQL PRIMARY KEY 约束

已 被 ， 如需 «P_Id» 列 创建 PRIMARY KEY ， 的 SQL ：

MySQL / SQL Server / Oracle / MS Access ：

ALTER TABLE Лица
ДОБАВИТЬ ПЕРВИЧНЫЙ КЛЮЧ (P_Id)

PRIMARY KEY 并 定义 多个 的 PRIMARY KEY ， 请 使用 的 SQL 语法 ：

MySQL / SQL Server / Oracle / MS Access ：

ALTER TABLE Лица
ДОБАВИТЬ ОГРАНИЧЕНИЕ ПЕРВИЧНЫЙ КЛЮЧ pk_PersonID (P_Id, LastName)

注释 ： 如果 您 使用 ALTER TABLE 语句 添加 主 键 ， 必须 把 主 声明 为 不 包含 NULL 值 （在 表 首次 创建 时）。

撤销 ПЕРВИЧНЫЙ КЛЮЧ 约束

PRIMARY KEY 约束 ， 请 使用 的 SQL ：

MySQL ：

ALTER TABLE Лица
УДАЛИТЬ ПЕРВИЧНЫЙ КЛЮЧ

SQL Server / Oracle / MS Access ：

ALTER TABLE Лица
ОГРАНИЧЕНИЕ УДАЛЕНИЯ pk_PersonID

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

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

Введение в ограничение PRIMARY KEY

Ограничение PRIMARY KEY объявляет столбец или комбинацию столбцов, значения которых однозначно идентифицируют каждую строку в таблице. Этот столбец или комбинация столбцов также называется первичным ключом таблицы. Если вы вставляете или обновляете строку, которая может вызвать дублирование первичного ключа, механизмы SQL выдадут сообщение об ошибке. Другими словами, ограничение PRIMARY KEY помогает автоматически обеспечивать целостность данных.

Существует несколько правил, которым должен следовать первичный ключ:

• Для каждой таблицы существует только один первичный ключ.
• Если первичный ключ является столбцом, значение этого столбца должно быть уникальным и не должно NULL . Если первичный ключ состоит из нескольких столбцов, каждая комбинация значений в этих столбцах должна быть уникальной.
• Первичный ключ может быть определен как часть определения столбца, если он состоит из одного столбца. Если первичный ключ состоит из нескольких столбцов, он должен быть определен в конце оператора CREATE TABLE.
• Существует ограничение на тип данных столбца первичного ключа e.g., это не может быть BLOB , CLOB , ARRAY или NCLOB .

Мы часто создаем ограничение первичного ключа во время создания таблицы. Мы также можем добавить ограничение PRIMARY KEY к существующей таблице, которая не имеет ограничения PRIMARY KEY , используя оператор ALTER TABLE. Кроме того, мы можем изменить или удалить существующее ограничение PRIMARY KEY таблицы.

Примеры ограничений PRIMARY KEY

Давайте рассмотрим несколько примеров использования ограничений PRIMARY KEY .

Ограничение PRIMARY KEY, состоящее из 1 столбца, пример

В этом примере мы создаем таблицу журналов для хранения журналов транзакций. Журналы Таблица состоит из двух столбцов: LogID и Сообщение . LogID является первичным ключом таблицы журналов . Мы определяем ограничение PRIMARY KEY как часть определения столбца в следующем операторе CREATE TABLE :

Столбец LogID определен как:

• NOT NULL : значение в столбце не может быть NULL .В некоторых системах управления базами данных, если вы определяете столбец как PRIMARY KEY , ему неявно назначается атрибут NOT NULL .
• AUTO_INCREMENT : механизм базы данных генерирует последовательность для столбца всякий раз, когда в таблицу вставляется новая строка. AUTO_INCREMENT - это атрибут MySQL. Атрибут AUTO_INCREMENT может быть определен как IDENTITY в SQL-сервере, SERIAL в PostgreSQL.

PRIMARY KEY ограничение, состоящее из более чем одного столбца Пример

Давайте взглянем на таблицу orderdetails в базе данных примера:

Что такое реляционные схемы и первичный ключ SQL

В этом руководстве мы будем использовать базу данных под названием « Sales », чтобы немного лучше проиллюстрировать концепцию реляционных схем и познакомить вас с SQL первичный ключ .Данные будут храниться в 4 таблицах - « Продажи », « Клиентов », « Товаров » и « Компаний ».

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

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

Пример таблицы

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

Поля таблицы

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

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

Люди могли купить много единиц одного и того же продукта; следовательно, есть возможность увидеть один и тот же код товара несколько раз в последнем столбце.

Что такое первичный ключ SQL

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

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

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

В одной таблице не может быть 3 или 4 первичных ключа. Например, в нашей таблице « Продажи » Purchase_number может выступать в качестве первичного ключа с одним столбцом, и других первичных ключей не будет.

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

Пример многоколоночного первичного ключа

Например, покупка номер 1 и дата покупки, которая приходится на 3 сентября, образуют уникальную пару, так же как покупка номер 2 и та же дата, 3 сентября. Это означает, что эти 2 ряда разные.

Дополнительное примечание: Не упускайте из виду тот факт, что в вашей таблице не может быть комбинации одного и того же номера покупки, 1, и одной и той же даты, 3 сентября, более одного раза. Либо число, либо дата должны отличаться. Это потому, что, как мы уже говорили, первичный ключ должен быть уникальным.

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

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

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

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

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

Будьте осторожны и не забывайте об этой характеристике первичного ключа!

Как создать реляционную схему

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

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

Информация, которую вы получаете

Помня об этих простых правилах, когда вы заметите эту таблицу, вы сразу поймете: она называется « Продажи »; его первичный ключ - purc hase_number ; и есть еще три поля - date_of_purchase, customer_ID, item_code.

Это изображение соответствует табличным данным в следующем виде:

Последнее замечание о первичном ключе SQL

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

Резюме:

Реляционные схемы

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

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

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