Что называется первичным ключом в бд. Первичные ключи

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

СУБД – это программные средства для создания, наполнения, обновления и удаления БД.

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

В терминах БД столбцы таблицы называются полями, а её строки – записями.

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

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

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

Сущность – отражение объекта в памяти человека или компьютера.

Атрибут – конкретное значение любого из свойств сущности.

Поле – это один элемент записи, в котором хранится конкретное значение атрибута.

Поле связи – это поле, по которому две таблицы связаны.

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

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

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

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

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

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

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

Реляционные отношения между таблицами

Один-к-одному. Отношение один-к-одному имеет место, когда одной записи в родительской таблице соответствует одна запись в дочерней таблице.

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

Подобно связи один-ко-многим, связь один-к-одному может быть жесткой и нежесткой.

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

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

В базе данных первичный ключ таблицы - это один из ее столбцов (Primary key). Разберемся на примере, как это выглядит. Представим простое отношение студентов университета (назовем его "Студенты").

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

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

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

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

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

Связи между отношениями

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

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

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

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

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

Внешний ключ и целостность данных в БД

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

Важным принципом построения баз данных является их целостность. И одно из ее правил - целостность по ссылкам. Это значит, что внешний ключ таблицы не может ссылаться на несуществующий Primary key другого отношения. Нельзя удалить из отношения "Студент" запись с кодом 1000 - Иванов Иван, если на нее ссылается запись из таблицы успеваемости. В правильно построенной БД при попытке удаления вы получите ошибку, что это поле используется.

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

Таблицы

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

Таблица – это некоторая регулярная структура, состоящая из конечного набора однотипных записей.

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

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

В любой таблице всегда есть как минимум 1 столбец. В стандарте ANSI/ISO не указывается максимально допустимое число столбцов в таблице, однако почти во всех коммерческих СУБД этот предел существует. В СУБД Firebird этот предел составляет 32 767 столбцов.

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

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

Рис. 1.1. Структурареляционной таблицы Abonent

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

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

На пересечении каждой строки с каждым столбцом таблицы содержится в точности одно значение данных. Например, в строке, представляющей абонента Конюхова В. С., в столбце Fio содержится значение "Конюхов В.С.". В столбце AccountCD той же строки содержится значение "015527", которое является номером лицевого счета абонента с ФИО Конюхов В. С.

Все значения, содержащиеся в одном и том же столбце, являются данными одного типа. Например, в столбце Fio содержатся только слова, а в столбце StreetCD содержатся целые числа, представляющие идентификаторы улиц. В реляционной модели данных общая совокупность значений, из которой берутся действительные значения для определенных атрибутов (столбцов), называется доменом . Доменом столбца Fio, например, является множество фамилий, имен и отчеств (ФИО) абонентов. Каждый столбец всегда определяется на одном домене.

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

В учебной базе данных определены следующие домены:

§ Boollean (Логический): SMALLINT . Поля, определяемые на этом домене, могут принимать только целочисленные значения, равные 0 или 1. Это достигается наложением в домене условия проверки (CHECK) на принимаемые этим доменом значения.

§ Money (Деньги): NUMERIC(15,2) . Домен предназначен для определения в таблицах полей, хранящих денежные суммы.

§ PKField (Поле ПК): INTEGER . Домен предназначен для определения первичных и внешних ключей таблиц. Ограничение обязательности данных (NOT NULL) на этот домен не наложено. Оно накладывается при объявлении первичного ключа таблицы. Это сделано для того, чтобы можно было определить внешний ключ на этом домене без условия NOT NULL.

§ TMonth (Месяц): SMALLINT . Домен предназначен для определения в таблицах полей, содержащих номера месяцев. Целочисленные значения в таком поле могут находиться в диапазоне 1...12.

§ TYear (Год): SMALLINT . Домен предназначен для определения полей, содержащих номер года. Целочисленные значения могут находиться в диапазоне 1990...2100.

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

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

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

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

Вернемся к рассмотрению таблицы Abonent учебной базы данных (рис. 1.1). На первый взгляд, первичным ключом таблицы Abonent могут служить и столбец AccountCD, и столбец Fio. Однако в случае если будут зарегистрированы 2 абонента с одинаковыми ФИО, то столбец Fio больше не сможет исполнять роль первичного ключа. На практике в качестве первичных ключей таблиц обычно следует выбирать идентификаторы, такие как уникальный номер лицевого счета абонента (AccountCD в таблице Abonent), идентификатор улицы (StreetCD в таблице Street) и т. д.

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

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

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

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

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

Понятия первичного ключа мы уже вскользь касались в статье, посвященной нормализации базы данных. Первичный ключ - это столбец или группа столбцов, однозначно определяющие запись. Первичный ключ по определению уникален: в таблице не может быть двух разных строк с одинаковыми значениями первичного ключа. Столбцы, составляющие первичный ключ, не могут иметь значение 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 поддерживала ссылочную целостность (без ущерба для производительности:).