Доброго времени суток, читатели, зрители моего канала programmer's notes. Не забывайте подписываться и писать свои комментарии к моим статьям и видео.
Приложение к видео
Первичные ключи в реляционных базах данных
Первичный ключ (Primary Key, PK, ПК) является центральным понятием реляционных баз данных. В первой лекции по БД я вводил его как данность, попробуем теперь провести цепочку рассуждений приводящих к понятию первичного ключа.
На рисунке 1 представлена таблица, описывающая сущность предметной области "Студент". Ранее я говорил, что атрибут, свойство сущности, отображением которой является таблица, соответствует столбцу таблицы. Теперь есть смысл обобщить понятие атрибута. Будем называть простым атрибутом атрибут состоящий из одного столбца. Несколько же столбцов образует составной атрибут.
На рисунке 2 представлены примеры атрибутов. Заметим, что порядок следования имен столбцов в атрибуте не имеет значения, т.е. перестановка столбцов в атрибуте не приводит к появлению нового атрибута.
На прошлой лекции я говорил о том, что в реляционных базах данных строки таблиц неупорядочены, а значит отличаться строки могут только своим содержимым. Две полностью совпадающих строки это нонсенс, так как не могут быть два полностью идентичных экземпляра сущности. Отсюда простой вывод: должен существовать по-крайней мере один атрибут, который однозначно определяет строку таблицы. Ну хотя бы атрибут, состоящий из всех столбцов. Такой атрибут будем называть ключом (см. рисунок 3).
Очень важное замечание
Понятие ключа содержит в себе важное допущение, что он однозначно определяет строку в таблице. Это всегда требует определённого рассуждения или исследования. Ведь есть малая вероятность, например, что <ФИО, Адрес> может повторится. Да, это маловероятно, но всё же. Так что об этом никогда не забываем.
Мы видим, что есть простые ключи, состоящие из одного столбца и есть составные. Также обратим внимание ещё на то, что некоторые ключи могут содержать в себе другие ключи. Выделим те ключи, которые не содержать в себе других ключей. Такие ключи будем называть возможными или потенциальными (см. Рисунок 4).
Что это значит? Один из возможных ключей выбирается в качестве первичного ключа (Primary Key). Вот это есть тот самый важный момент. Какой выбрать ключ.
1. Не удобно работать с составным ключом. Поэтому составные ключи мы сразу отбрасываем. Только простые ключи.
2. Смотрим на рисунок 5. Все столбцы, ну кроме id, являются свойствами реальной сущности. Такого типа ключи называются естественными. А вот id, который обычно является счетчиком добавляемых строк (но не обязательно) не имеет никакого отношения к сущности. Такой ключ будет называть суррогатным.
При выборе ключа всегда будет выигрывать суррогатный ключ. Почему?
1. Значение естественного ключа на время добавления строки может быть неизвестно. СУБД не позволит вам добавить такую строку. Это большой минус.
2. Значения естественного ключа может по ошиб совпадать. И опять получим проблему добавления.
3. Значение естественного ключа может со временем меняться, а это приведёт к дополнительным проблемам в связям между таблицами, так связь как раз и основывается первичных ключах.
Наконец ещё одно свойство первичного ключа следует не забывать. Это свойство можно назвать областью уникальности. Обычно эта область распространяется на одну таблицу, если речь идёт о счетчике добавляемых строк. Но иногда требуется расширить область, например, чтобы искать по разным таблицам и базам данных. Это, конечно, особый вопрос, но он имеет место быть. Также он возникает, если вам нужно объединить несколько таблиц в одну, сохранив значения первичных ключей. Попробуйте это сделать, если значения первичных ключей совпадают.
Ну, пока всё!
Пишите свои предложения и замечания и занимайтесь программированием, а также проектированием баз данных, хотя бы для поддержания уровня интеллекта.