Что это — первичный ключ в базе данных?

Пример приведения таблицы ко второй нормальной форме

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

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

ФИО	Должность	Подразделение	Описание подразделения
Иванов И.И.	Программист	Отдел разработки	Разработка и сопровождение приложений и сайтов
Сергеев С.С.	Бухгалтер	Бухгалтерия	Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности
John Smith	Продавец	Отдел реализации	Организация сбыта продукции

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

Теперь мы можем начать процесс нормализации этой таблицы до второй нормальной формы.

Что для этого нам нужно сделать? Нам нужно внедрить первичный ключ.

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

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

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

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

Табельный номер	ФИО	Должность	Подразделение	Описание подразделения
1	Иванов И.И.	Программист	Отдел разработки	Разработка и сопровождение приложений и сайтов
2	Сергеев С.С.	Бухгалтер	Бухгалтерия	Ведение бухгалтерского и налогового учета финансово-хозяйственной деятельности
3	John Smith	Продавец	Отдел реализации	Организация сбыта продукции

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

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

Удалить первичный ключ

В SQL вы можете удалить первичный ключ, используя оператор ALTER TABLE.

Синтаксис

Синтаксис для удаления первичного ключа в SQL.

ALTER TABLE table_name DROP PRIMARY KEY;

table_name

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

Пример

Давайте посмотрим, как удалять первичный ключ с помощью оператора ALTER TABLE в SQL.

PgSQL

ALTER TABLE suppliers
DROP PRIMARY KEY;

1 2	ALTERTABLEsuppliers DROPPRIMARYKEY;

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

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

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

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

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

Внешние ключи

• Если сущности А и В связывает сущность С, то она должна содержать внешние ключи, которые соответствуют первичным ключам сущностей А и В.
• Если сущность В характеризует сущность А, то она должна содержать внешний ключ, который соответствует первичному ключу сущности А.

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

1-й вопрос: может ли значение данного внешнего ключа быть неопределенным (NULL-значением)?

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

2-й вопрос: что должно произойти при УДАЛЕНИИ экземпляра сущности с первичным ключом, на который ссылается внешний ключ?

Например, если удаляется поставщик, осуществивший хотя бы одну поставку, существует 3 варианта, при которых поставка:

• КАСКАДИРУЕТСЯ – удаляются все поставки данного поставщика.
• ОГРАНИЧИВАЕТСЯ – удаляются только не осуществлявшие поставок поставщики. В противном случае удаление отклоняется.
• УСТАНАВЛИВАЕТСЯ – для всех поставок данного поставщика значение внешнего ключа устанавливается в NULL (неопределенное), а после данный поставщик удаляется. Подобная возможность, естественно, не может быть применена, если внешний ключ не может содержать неопределенных значений (NULL).

3-й вопрос – какая операция должна выполняться при ОБНОВЛЕНИИ первичного ключа сущности, на который ссылается внешний ключ?

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

• КАСКАДИРУЕТСЯ – обновляется также и внешний ключ в поставках данного поставщика.
• ОГРАНИЧИВАЕТСЯ – обновляются первичные ключи только не осуществлявших поставок поставщиков, в противном случае операция обновления отклоняется.
• УСТАНАВЛИВАЕТСЯ – для всех поставок поставщика, который обновляется, внешний ключ устанавливается в NULL-значение, а после выполняется обновление первичного ключа поставщика. Подобная возможность, естественно, не может быть применена, если внешний ключ не может содержать неопределенных значений (NULL).

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

Какие типы СУБД в соответствии с моделями данных вы знаете?

Этот вопрос по SQL предполагает не просто назвать, но и дать краткое описание каждому типу.

Существует несколько типов СУБД:

1. Реляционные, которые поддерживают установку связей между таблицами с помощью первичных и внешних ключей. Пример — MySQL.
2. Flat File — базы данных с двумерными файлами, в которых содержатся записи одного типа и отсутствует связь с другими файлами, как в реляционных. Пример — Excel.
3. Иерархические подразумевают наличие записей, связанных друг с другом по принципу отношений один-к-одному или один-ко-многим. А вот для отношений многие-ко-многим следует использовать реляционную модель. Пример — Adabas.
4. Сетевые похожи на иерархические, но в этом случае «ребёнок» может иметь несколько «родителей» и наоборот. Примеры — IDS и IDMS.
5. Объектно-ориентированные СУБД работают с базами данных, которые состоят из объектов, используемых в ООП. Объекты группируются в классы и называются экземплярами, а классы в свою очередь взаимодействуют через методы. Пример — Versant.
6. Объектно-реляционные обладают преимуществами реляционной и объектно-ориентированной моделей. Пример — IBM Db2.
7. Многомерная модель является разновидностью реляционной и использует многомерные структуры. Часто представляется в виде кубов данных. Пример — Oracle Essbase.
8. Гибридные состоят из двух и более типов баз данных. Используются в том случае, если одного типа недостаточно для обработки всех запросов. Пример — Altibase HDВ.

3

6.1.Понятие реляционной базы данных

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

Таблица
2

№№	ИМЯ ПОЛЯ	ТИП ПОЛЯ
1	Фамилия	Текстовый
2	Имя	Текстовый
3	Отчество	Текстовый
4	Почтовый индекс	Текстовый
5	Страна	Текстовый
6	Город	Текстовый
7	Адрес	Текстовый
8	Кредит	Денежный
9	Примечание	МЕМО или OLE
10	Категория товара	Текстовый
11	Наименование товара	Текстовый
12	Фирма-производитель	Текстовый
13	Цена	Денежный
14	Дата заказа	Дата/Время
15	Заказано	Числовой
16	Дата продажи	Дата/Время
17	Продано	Числовой

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

Поэтому
целесообразно разбить эту таблицу
на четыре таблицы “КЛИЕНТЫ”, “ЗАКАЗЫ
И ПРОДАЖИ”, “ТОВАРЫ” и «ПОСТАВЩИКИ»,
установив связи между ними, например,
так, как показано на рис. 6.1.

Рис.
6.1. Схема данных в реляционной БД

Реляционная
база данных
– совокупность некоторых таблиц с
данными, взаимосвязанных между собой
определёнными логическими соотношениями
(relation).

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

Primary key может быть простым и составным. Если уникальность записи определяется значением только в одном поле, как описано выше, мы имеем дело с простым ключом. Составной ключ – это первичный ключ базы данных, состоящий из двух и более полей. Рассмотрим следующее отношение клиентов банка.

Ф. И. О.	Дата рождения	Серия паспорта	Номер паспорта
Иванов П.А.	12.05.1996	75	0553009
Сергеев В.Т.	14.07.1958	71	4100654
Краснов Л.В.	22.01.2001	73	1265165

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

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

Столбец первичного ключа в таблице помогает идентифицировать каждую строку или запись в таблице. Содержит уникальные значения. Столбец первичного ключа не может иметь значения Null. Таблица может иметь один первичный ключ. В таблице Student, student_id является первичным ключом. В таблице Patient_Details, Patient_id является первичным ключом. Для первичного ключа необязательно иметь одно поле. Это также может быть комбинация нескольких полей. Когда первичный ключ состоит из нескольких полей, он называется составным ключом. Например, первичный ключ таблицы Student может быть комбинацией student_id и name.

Суррогатные ключи

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

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

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

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

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

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

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

счетчик, простой ключ и составной ключ.

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

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

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

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

Типы связей и их реализация. Ссылочная целостность и ее обеспечение.

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

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

Виды
связей между таблицами

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

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

Связи
«один ко многим»

Связь
«один ко многим» — наиболее
распространенный вид связи. При такой
связи каждой строке таблицы А может
соответствовать множество строк таблицы
Б, однако каждой строке таблицы Б может
соответствовать только одна строка
таблицы А. Например, между таблицами
«Издатели» и «Книги» установлена
связь «один ко многим»: каждый из
издателей может опубликовать множество
книг, однако каждая книга публикуется
лишь одним издателем.

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

В
Microsoft Access сторона связи «один ко
многим», которой соответствует
первичный ключ, обозначается символом
ключа. Сторона связи, которой соответствует
внешний ключ, обозначается символом
бесконечности.

Связи
«многие ко многим»

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

Связи
«один к одному»

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

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

• Чтобы
разделить таблицу, содержащую слишком
много столбцов.

• Чтобы
изолировать часть таблицы по соображениям
безопасности.

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

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

В
Microsoft Access сторона связи «один к одному»,
которой соответствует первичный ключ,
обозначается символом ключа. Сторона
связи, которой соответствует внешний
ключ, также обозначается символом ключа.

Создание
связей между таблицами

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

Ключевое поле

Ключевое поле

Это та запись, которая определяет запись в таблице.

Нажимаем в колонке слева на названии таблицы Читатель. Справа появилась таблица. Правой кнопкой нажимаем на названии – конструктор – в пустом поле пишем код читателя.

Сделаем это поле ключевым (на панели задач – ключевое поле) и закроем таблицу.

Это первичный ключ. Для ключевых полей используют тип – счетчик или числовой.

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

Книги – код книги.

Издательство – код издательства (тип данных –мастер подстановок – Издательство- выберите поле код и наименование).

Выдача – код выдачи (код читателя – таблица Читатель /код читателя и фамилия/ и код книги – таблица Книги/ код книги и название).

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

Связывание таблиц

Переходим на вкладку – Работа с базами данных – схема данных – появилось окно.

Поочередно нажимаем на название каждой таблицы и закрываем окно.

Появилась схема данных. Определим как будем связывать таблицы.

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

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

Аналогично свяжем две другие таблицы.

Откроем таблицу Выдача через конструктор. Добавляем поле Код читателя.

Сохраняем, закрываем.

Теперь Код читателя таблицы Читатель переносим на Код читателя таблицы Выдача.

Ставим везде галочки — создать. Появилась связь (читатель берет много книг).

Теперь свяжем таблица Книги и Выдача. Для этого в таблицу Выдача добавим Код книги. И проделаем те же манипуляции.

Заполнение таблиц

Берем таблицу Читатель. Код читателя ставим на первое место. Нумерация будет автоматическая в этом поле. Вводим остальные данные (не менее 10) и сохраняем правой кнопкой.

Заполняем остальные таблицы по аналогии.

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

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

Рисунок 1: Первичный и Внешний ключ

Например, предположим, что есть база данных продаж. Имеются таблицы клиентов и продуктов. Таблица customer содержит столбцы customer_id, name, address и contact_no. Первичный ключ таблицы клиента — customer_id. Товар имеет столбцы product_id, name, quality. Первичный ключ таблицы продукта — product_id. Размещение product_id в таблице клиентов создаст связь между двумя таблицами. Product_id в таблице product является первичным ключом, но это внешний ключ в customer_table. Аналогично, можно соединять таблицы в базе данных, используя внешний ключ.

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

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

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

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

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

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

Мы уже достаточно много говорили про ключевые поля, но ни разу их не использовали. Самое интересное, что все работало. Это преимущество, а может недостаток базы данных Microsoft SQL Server и MS Access. В таблицах Paradox такой трюк не пройдет и без наличия ключевого поля таблица будет доступна только для чтения.

В какой-то степени ключи являются ограничениями, и их можно было рассматривать вместе с оператором CHECK, потому что объявление происходит схожим образом и даже используется оператор CONSTRAINT. Давайте посмотрим на этот процесс на примере. Для этого создадим таблицу из двух полей «guid» и «vcName». При этом поле «guid» устанавливается как первичный ключ:

CREATE TABLE Globally_Unique_Data
(
 guid uniqueidentifier DEFAULT NEWID(),
 vcName varchar(50),
 CONSTRAINT PK_guid PRIMARY KEY (Guid)
)

Самое вкусное здесь это строка CONSTRAINT. Как мы знаем, после этого ключевого слова идет название ограничения, и объявления ключа не является исключением. Для именования первичного ключа, я рекомендую использовать именование типа PK_имя, где имя – это имя поля, которое должно стать главным ключом. Сокращение PK происходит от Primary Key (первичный ключ).

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

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

В данном примере, в качестве первичного ключа выступает поле типа uniqueidentifier (GUID). Значение по умолчанию для этого поля – результат выполнения серверной процедуры NEWID.

Внимание

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

Для простоты примеров, в качестве ключа желательно использовать численный тип и если позволяет база данных, то будет лучше, если он будет типа «autoincrement» (автоматически увеличивающееся/уменьшающееся число). В MS SQL Server таким полем является IDENTITY, а в MS Access это поле типа «счетчик».

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

CREATE TABLE Товары
(
  id int IDENTITY(1, 1),
  товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY (id)
)

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

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

CREATE TABLE Товары1
(
  id int IDENTITY(1, 1),
  Товар varchar(50),
  Цена money,
  Количество numeric(10, 2),
  CONSTRAINT PK_id PRIMARY KEY 
         (id, )
)

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

Единственный недостаток первичного ключа из нескольких колонок – проблемы создания связей. Тут приходиться выкручиваться различными методами, но проблема все же решаема. Достаточно только ввести поле типа uniqueidentifier и производить связь по нему. Да, в этом случае у нас получаются уникальными первичный ключ и поле типа uniqueidentifier, но эта избыточность в результате не будет больше, чем та же таблица, где первичный ключ uniqueidentifier, а на поля, которые должны быть уникальными установлено ограничение уникальности. Что выбрать? Зависит от конкретной задачи и от того, с чем вам удобнее работать.

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

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

Внешний ключ

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

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

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