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

Обновлено: 14.01.2025

Из статьи вы узнаете, что такое первичный и внешний ключ в SQL. Зачем они нужны и как их использовать. Я покажу на практике как их использовать в PostgreSQL.

Теория

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

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

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

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

Первичный ключ может быть:

естественным – существует в реальном мире, например ФИО, или номер и серия паспорта;
суррогатным – не существует в реальном мире, например какой-то порядковый номер, который существует только в базе данных.

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

Связь между таблицами

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

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

Например, у вас есть таблица “Ученики” (pupils) и выглядит она следующим образом:

ФИО full_name	Возраст age	Класс class
Иванов Иван Иванович	15	9А
Сумкин Фёдор Андреевич	15	9А
Петров Алексей Николаевич	14	8Б
Булгаков Александр Геннадьевич	14	8Б

Таблица pupils

И есть таблица “Успеваемость” (evaluations):

Предмет item	ФИО full_name	Оценка evaluation
Русский язык	Иванов Иван Иванович	4
Русский язык	Петров Алексей Николаевич	5
Математика	Булгаков Александр Геннадьевич	3
Литература	Сумкин Фёдор Андреевич	5

Таблица evaluations

В обоих таблицах есть одинаковое поле: ФИО. При этом в таблице “Успеваемость” не может содержаться ФИО, которого нет в таблице “ Ученики“. Ведь нельзя поставить ученику оценку, которого не существует.

Первичным ключом в нашем случае может выступать поле “ФИО” в таблице “ Ученики“. А внешним ключом будет “ФИО” в таблице “Успеваемость“. При этом, если мы удаляем запись о каком-то ученике из таблицы “Ученики“, то все его оценки тоже должны удалиться из таблицы “Успеваемость“.

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

составной первичный ключ – например, в качестве первичного ключа взять два поля: ФИО и Класс;
суррогатный первичный ключ – в таблице “Ученики” добавить поле “№ Ученика” и сделать это поле первичным ключом;
добавить более уникальное поле – например, можно использовать уникальный номер зачетной книжки и использовать новое поле в качестве первичного ключа;

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

Практика

Создадим базу данных school и подключимся к ней. Затем создадим таблицу pupils. Про создание таблиц я уже писал тут, а про типы данных тут. Затем посмотрим на табличку с помощью команды \d:

Как вы могли заметить, первичный ключ создаётся с помощью конструкции PRIMARY KEY (имя_поля) в момент создания таблицы.

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

поле full_name, к которому относится первичный ключ не может быть пустым, это видно в колонки Nullable – not null;
для поля full_name был создан индекс pupils_pkey с типом btree. Про типы индексов и про сами индексы расскажу в другой статье.

Индекс в свою очередь наложил ещё одно ограничение – записи в поле full_name должны быть уникальны.

Следующим шагом создадим таблицу evaluations:

В этом случае из вывода команды \d вы увидите, что создался внешний ключ (Foreign-key), который относится к полю full_name и ссылается на таблицу pupils.

Внешний ключ создается с помощью конструкции FOREIGN KEY (имя_поля) REFERENCES таблица_на_которую_ссылаются.

Создавая внешний ключ мы дополнительно указали опцию ON DELETE CASCADE. Это означает, что при удалении строки с определённым учеником в таблице pupils, все строки связанные с этим учеником удалятся и в таблице evaluations автоматически.

Заполнение таблиц и работа с ними

Заполним таблицу “pupils“:

Заполним таблицу “evaluations“:

А теперь попробуем поставить оценку не существующему ученику:

Как видите, мы получили ошибку. Вставлять (insert) или изменять (update) в таблице evaluations, в поле full_name можно только те значения, которые есть в этом же поле в таблице pupils.

Теперь удалим какого-нибудь ученика из таблицы pupils:

И посмотрим на строки в таблице evaluations:

Как видно, строка с full_name равная ‘Иванов Иван Иванович’ тоже удалилась. Если бы у Иванова было бы больше оценок, они всё равно бы все удалились. За это, если помните отвечает опция ON DELETE CASCADE.

Попробуем теперь создать ученика с точно таким-же ФИО, как у одного из существующих:

Ничего не вышло, так как такая запись уже существует в поле full_name, а это поле у нас имеет индекс. Значит значения в нём должны быть уникальные.

Составной первичный ключ

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

Давайте удалим наши таблички и создадим их заново, но теперь создадим их используя составной первичный ключ:

Как вы могли заметить, разница не большая. Мы должны в PRIMARY KEY указать два поля вместо одного. И в FOREIGN KEY точно также указать два поля вместо одного. Ну и не забудьте в таблице evaluations при создании добавить поле class, так как его там в предыдущем варианте не было.

Теперь посмотрим на структуры этих таблиц:

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

Теперь мы можем учеников с одинаковым ФИО вбить в нашу базу данных, но при условии что они будут учиться в разных классах:

И также по второй таблице:

Удаление таблиц

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

Поэтому удалим наши таблицы в следующем порядке:

Либо мы могли удалить каскадно таблицу pupils вместе с внешним ключом у таблицы evaluations:

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

Создание связи в уже существующих таблицах

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

Вначале удалим оставшуюся таблицу:

И сделаем таблицы без ключей:

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

И создадим внешний ключ в таблице evaluations:

Посмотрим что у нас получилось:

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

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

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

По умолчанию Oracle разрешает значения null во всех столбцах. Если эти значения недопустимы для некоторых столбцов таблицы, для них необходимо задавать ограничение NOT NULL. Обратите внимание, что налагать ограничения базы данных на таблицы можно как во время их создания, так и позднее, с помощью команды ALTER TABLE.Однако очевидно, что если в таблице уже имеются значения null или дублированные данные, то изменить таблицу, применив ограничение NOT NULL или ограничение уникальности, будет невозможно.

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

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

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

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

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

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

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

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

На заметку! В обоих предыдущих примерах Oracle автоматически создает индексы на столбце,который назначен первичным ключом.

Ограничения NOT NULL

Обычно таблица имеет один или более столбцов, в которых не допускается значение null — т.е. без значений. Хорошим примером является столбец last_name таблицы employee. Заставить пользователей обязательно вносить значения в этот столбец можно при создании таблицы, указав опцию NOT NULL для столбца, который не должен быть null:

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

Проверочные ограничения

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

Ограничение уникальности

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

В следующем примере первый оператор специфицирует ограничение уникальности на комбинации столбцов dept_name и location:

Создать уникальное ограничение на таблице department можно также с помощью такого оператора ALTER TABLE:

Ограничения ссылочной целостности

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

Гарантировать существование действительного департамента можно с помощью ограничения ссылочной целостности. В этом случае столбец departament_id служит первичным ключом таблицы dept, а столбец dept_id в таблице employee, ссылающийся на соответствующий столбец таблицы department, называется внешним ключом. Таблица,содержащая внешний ключ, обычно называется дочерней таблицей, а таблица, содержащая ключ, на который ссылается внешний ключ — родительской таблицей. Как и со всеми прочими типами ограничений, ссылочные ограничения целостности можно создавать во время создания таблицы или позднее, с помощью оператора ALTER TABLE:

База данных назначает столбец dept_id таблицы employee внешним ключом, потому что он ссылается на столбец dept_id таблицы dept. Обратите внимание, что для того, чтобы столбец служил ссылочным (на который ссылаются), он должен быть уникальным или же быть первичным ключом в таблице, на которую установлена ссылка.

Состояния ограничений целостности

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

При загрузке больших объемов данных с использованием SQL*Loader или утилиты Import может потребоваться значительное время на загрузку данных, каждую строку которых нужно проверять на предмет нарушения целостности. Более эффективная стратегия предусматривает отключение ограничения, загрузку данных и последующую проверку корректности загруженных данных. После завершения загрузки ограничения вновь вводятся в действие посредством включения. Когда ограничение отключается,как описано здесь, база данных уничтожает индекс. Подобным образом реализуется лучшая стратегия — предварительное создание неуникальных индексов для ограничений, которые база данных не должна уничтожать, поскольку они обрабатывают дублированные записи.

На заметку! Состояние enabled (включено) — это состояние ограничений Oracle по умолчанию

Отключаются ограничения двумя способами: указание в качестве состояния ограничения либо disable validate (отключить с проверкой), либо disable no validate (отключить без проверки) с использованием конструкции DISABLE VALIDATE и DISABLE NO VALIDATE, соответственно. Аналогично, для включения ограничения применяются конструкции ENABLE VALIDATE и ENABLE NO VALIDATE. Ниже кратко обсуждаются различные способы включения и отключения ограничений.

Состояние Disable Validate

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

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

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

Состояние Disable No Validate

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

Состояние Enable Validate

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

Состояние Enable No Validate

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

Более подходящая стратегия заключалась бы в использовании состояния DISABLE NOVALIDATE при загрузке данных, с переходом к состоянию ENABLE NOVALIDATE и затем к ENABLE VALIDATE в конце цикла извлечения, трансформации и загрузки (extraction,transformation, loading — ETL).

Ограничения Rely

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

Отложенные и немедленные ограничения

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

Если хотите, чтобы ограничение проверялось немедленно после модификации данных, выберите опцию not defferable (не откладывая), которая, фактически задает поведение по умолчанию в базах данных Oracle. Если необходимо выполнить едино-временную проверку ограничения после фиксации всей транзакции, выберите опцию deferrable. Все ограничения и внешние ключи могут быть объявлены как deferrable или not deferrable.

В случае выбора опции deferrable появляются еще две дополнительных опции.Ограничение deferrable можно специфицировать либо как initially deferred, либо как initially immediate (изначально отложенное или изначально немедленное). В первом случае база данных откладывает проверки ограничения до окончания транзакции. Если же была выбрана опция initially immediate, то база данных проверит ограничения перед изменением любых данных. Обратите внимание, что если предварительно создается индекс, то он должен быть не уникальным, чтобы обработать дублированные значения.

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

В Oracle также предусмотрен способ изменения отложенного ограничения с immediate на deferred или наоборот с помощью следующих операторов:

Представления, относящиеся к ограничениям и индексам

DBA_CONSTRAINTS

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

Следующий запрос позволит узнать, какие ограничения установлены для таблицы TESTD. Ответ на запрос показывает, что таблица имеет единственное ограничение CHECK. Префикс SYS в столбце NAME отражает тот факт, что CONSTRAINT_NAME — имя по умолчанию, а не явно указанное владельцем таблицы.

Обратите внимание, что если необходимо увидеть определенное ссылочное ограничение и правило удаления, то нужно применить следующую вариацию предыдущего запроса:

DBA_CONS_COLUMNS

Представление DBA_CONS_COLUMNS показывает имя столбца и позицию в таблице,где определено ограничение:

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

Тем не менее, SQL поддерживает первичные ключи напрямую с ограничением PRIMARY KEY.

Функционально это то же самое, что и ограничение UNIQUE, за исключением того, что для данной таблицы можно определить только один PRIMARY KEY. PRIMARY KEY не допускает значения NULL.

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

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

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

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

Синтаксис:

Параметры:

название	Описание
table_name	Имя таблицы, в которой хранятся данные.
column1, column2	Наименование столбцов таблицы.
тип данных	Это char, varchar, целое число, десятичное число, дата и многое другое.
размер	Максимальная длина столбца таблицы.

Хорошая практика для первичных ключей в таблицах

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

Пример:

Имя поля	Тип данных	Размер	Десятичные знаки	НОЛЬ
agent_code	голец	6	нет	ОСНОВНОЙ КЛЮЧ
имя агента	голец	40	нет
рабочая область	голец	35	да
комиссия	десятичный	10	2	да
номер телефона	голец	17	да

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

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

Код SQL:

Ограничение первичного ключа на уровне таблицы:

Код SQL:

SQL CREATE TABLE с основным ограничением

SQL PRIMARY KEY CONSTRAINT является комбинацией ограничения NOT NULL и ограничения UNIQUE. Это ограничение гарантирует, что конкретный столбец или комбинация из двух или более столбцов для таблицы имеют уникальную идентификацию, которая помогает легче и быстрее найти конкретную запись в таблице.

Пример :

В следующем примере создается таблица. Вот имя поля и типы данных:

Имя поля	Тип данных	Размер	Десятичные знаки	НОЛЬ
agent_code	голец	6	нет	ОСНОВНОЙ КЛЮЧ
имя агента	голец	40	нет
рабочая область	голец	35	да
комиссия	десятичный	10	2	да
номер телефона	голец	17	да

можно использовать следующий оператор SQL:

Код SQL:

Чтобы увидеть структуру созданной таблицы:

Код SQL:

SQL CREATE TABLE с первичным ключом и уникальным ограничением

В следующем примере создается таблица. Вот имя поля и типы данных:

Имя поля	Тип данных	Размер	Десятичные знаки	НОЛЬ
cust_code	голец	6	нет	ОСНОВНОЙ КЛЮЧ
CUST_NAME	голец	25	нет	УНИКАЛЬНАЯ
cust_city	голец	25	нет
класс	целое число	да
agent_code	голец	6	нет

можно использовать следующий оператор SQL:

Код SQL:

Чтобы увидеть структуру созданной таблицы:

Код SQL:

SQL CREATE TABLE с PRIMARY KEY CONSTRAINT для большего количества столбцов

В следующем разделе мы обсудим использование SQL PRIMARY KEY CONSTRAINT вместе с оператором CREATE TABLE для двух или более столбцов.

Пример:

Имя поля	Тип данных	Размер	Десятичные знаки	НОЛЬ
cust_code	голец	6	нет	ОСНОВНОЙ КЛЮЧ
CUST_NAME	голец	25	нет
cust_city	голец	25	нет	ОСНОВНОЙ КЛЮЧ
класс	целое число	да
agent_code	голец	6	нет

можно использовать следующий оператор SQL:

Код SQL:

Чтобы увидеть структуру созданной таблицы:

Код SQL:

Упражнения по SQL

Упражнения по SQL, практика, решение
SQL Получить данные из таблиц [33 Упражнения]
Булевы и реляционные операторы SQL [12 упражнений]
Подстановочные знаки SQL и специальные операторы [22 упражнения]
Агрегатные функции SQL [25 упражнений]
Вывод запроса форматирования SQL [10 упражнений]
SQL-запросы к нескольким таблицам [7 упражнений]
ФИЛЬТРАЦИЯ И СОРТИРОВКА в базе данных персонала [38 упражнений]

SQL СОЕДИНЯЕТ

SQL СОЕДИНЯЕТСЯ [29 упражнений]
SQL присоединяется к базе данных HR [27 упражнений]

ПОДПИСИ SQL [39 упражнений]
SQL ПОДПИСИ по базе данных HR [55 упражнений]

ОСНОВНЫЕ запросы к базе данных фильмов [10 упражнений]
ПОДПИСКИ на фильм База данных [16 упражнений]
ПРИСОЕДИНЯЕТСЯ к базе данных фильма [24 упражнения]

Вступление
ОСНОВНЫЕ запросы по футболу базы данных [29 упражнений]
ПОДПИСКИ по футбольной базе данных [33 упражнения]

ПРИСОЕДИНЯЕТСЯ к запросам по футбольной базе данных [61 упражнений]

Вступление
ОСНОВНЫЕ, ПОДПИСИ И СОЕДИНЕНИЯ [39 упражнений]

ОСНОВНЫЕ запросы к базе данных сотрудников [115 упражнений]
БРОНИРОВАНИЕ на сотрудника База данных [77 Упражнения]

Хотите улучшить вышеуказанную статью? Вносите свои заметки / комментарии / примеры через Disqus.

Предыдущая: Создать таблицу
Далее: Внешний ключ

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

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

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

Синтаксис:

CREATE TABLE `customer` (
`cust_id` int(11) NOT NULL,
`cust_name` varchar(100) NOT NULL,
`cust_address` text NOT NULL,
`cust_aadhaar_number` varchar(50) DEFAULT NULL,
`cust_pan_number` varchar(50) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
ALTER TABLE `customer` ADD PRIMARY KEY (`cust_id`);

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

Тип SQL-ключей

SQL Server поддерживает несколько типов ключей.

Ниже приведен список ключей SQL:

Первичный ключ
Уникальный ключ
Ключ-кандидат
Альтернативный ключ
Композитный ключ
Супер Ключ
Иностранный ключ

Например

Таблица клиентов
cust_id	CUST_NAME	cust_address	cust_aadhaar_number	cust_pan_number
100001	Сунил Кумар	Нойды	372464389211	ADSFS3456K
100002	Анкит Гупта	Gr Noida	442289458453	CGHAD7583L
100003	Суреш Ядав	Нью-Дели	878453444144	NMKRT2278O
100004	Нилам Сингх	Лакхнау	227643441123	HFJFD3876U
100005	Амаль Рават	Газиабад	932571156735	CBMVA9734A
100006	Суровая Саксена	Канпер	1453534363319	TRYUC2568H

Ниже приведена таблица «Заказ», содержащая связанные данные, соответствующие «cust_id» из Таблицы клиентов.

Стол заказов
cust_id	order_month_year	сумма заказа
100001	2019 - январь	$ 100 000
100002	2019 - январь	$ 120 000
100003	2019 - январь	$ 100 000
100004	2019 - январь	$ 110 000
100001	2019 - февраль	$ 105000
100002	2019 - февраль	$ 125 000

Теперь мы пройдемся по одному на каждом из ключей:

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

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

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

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

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

Пример: в приведенной выше реляционной таблице «cust_aadhaar_number», «cust_pan_number» являются уникальным ключом, так как он может разрешить одно значение как NULL в столбце

3. Ключ-кандидат

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

Пример: в приведенной выше реляционной таблице «cust_id», «cust_aadhaar_number», «cust_pan_number» являются ключом-кандидатом, поскольку он может однозначно идентифицировать все строки из таблицы. Эти столбцы также квалифицируют критерии как первичный ключ.

4. Альтернативный ключ

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

Пример: в приведенной выше реляционной таблице «cust_aadhaar_number», «cust_pan_number» являются альтернативным ключом, поскольку оба столбца могут быть первичным ключом, но еще не выбраны для первичного ключа.

5. Композитный ключ

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

Пример: в приведенной выше реляционной таблице, т. Е. Таблице заказов, «cust_id», группе «order_month_year» этих столбцов, используемых в комбинации для уникальной идентификации кортежа в таблице заказов. Отдельный столбец этой таблицы не может однозначно идентифицировать кортеж из таблицы Order.

6. Супер Ключ

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

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

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

Пример: в приведенной выше реляционной таблице «cust_id» - это «Первичный ключ» в таблице «Клиент», а «cust_id» в таблице «Заказ», известный как «Внешний ключ». Внешний ключ в таблице всегда становится Первичным ключом на другой таблице.

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

Вывод - ключи SQL

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

Тип SQL-ключей

SQL Server поддерживает несколько типов ключей.

Ниже приведен список ключей SQL:

Первичный ключ
Уникальный ключ
Ключ-кандидат
Альтернативный ключ
Композитный ключ
Супер Ключ
Иностранный ключ

Например

Таблица клиентов
cust_id	CUST_NAME	cust_address	cust_aadhaar_number	cust_pan_number
100001	Сунил Кумар	Нойды	372464389211	ADSFS3456K
100002	Анкит Гупта	Gr Noida	442289458453	CGHAD7583L
100003	Суреш Ядав	Нью-Дели	878453444144	NMKRT2278O
100004	Нилам Сингх	Лакхнау	227643441123	HFJFD3876U
100005	Амаль Рават	Газиабад	932571156735	CBMVA9734A
100006	Суровая Саксена	Канпер	1453534363319	TRYUC2568H

Ниже приведена таблица «Заказ», содержащая связанные данные, соответствующие «cust_id» из Таблицы клиентов.

Стол заказов
cust_id	order_month_year	сумма заказа
100001	2019 - январь	$ 100 000
100002	2019 - январь	$ 120 000
100003	2019 - январь	$ 100 000
100004	2019 - январь	$ 110 000
100001	2019 - февраль	$ 105000
100002	2019 - февраль	$ 125 000

Теперь мы пройдемся по одному на каждом из ключей: