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

BestProg

Реляционные базы данных. Понятие ключа. Виды ключей. Отношения. Главная и подчиненная таблицы

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

Содержание

Поиск на других ресурсах:

Входные данные

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

Таблицы имеют следующую структуру.

Таблица «Работник». Содержит данные о работнике

Таблица «Зарплата». Содержит сведения о заработной плате работников.

Вопрос/ответ

1. Что такое первичный ключ в таблице базы данных? Для чего используются первичные ключи?

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

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

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

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

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

2. Что такое отношение (связь) между таблицами (relationship)? Пример

Таблицы в реляционной модели данных могут иметь связи между собой. Такие связи называются отношениями. Для таблиц «Работник» и «Зарплата» можно установить связь по полю «Табельный номер».

Пример. Проанализируем таблицы «Работник» и «Зарплата». В этих таблицах можно установить отношение между таблицами на основе поля «Табельный номер». То есть, связь между таблицами происходит на основе поля (атрибуту) «Табельный номер».

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

Рис. 1. Иллюстрация связи между таблицами. Табельный номер 2145 таблицы «Работник» отображается в таблице «Зарплата»

Рис. 2. Связь (отношение) между полями таблиц

3. Что такое внешний ключ (foreign key)? Пример

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

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

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

4. Что такое рекурсивный внешний ключ?

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

5. Могут ли первичный и внешний ключи быть простыми или составными (сложными)?

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

6. Какое отличие между искусственным и естественным ключом? Пример

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

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

Пример. В таблице «Работник» естественном ключом есть поле (атрибут) «Табельный номер». Поле «Табельный номер» есть само по себе уникальным, так как не может быть двух работников с одинаковым табельным номером.

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

где поле «Номер» есть искусственным ключом, который обеспечивает уникальность.

7. Какие существуют способы выбора первичного ключа?

Существует 3 способа выбора первичного ключа:

8. Что означают термины «главная таблица» (master) и «подчиненная таблица» (detail)?

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

Пример. Если рассмотреть таблицы «Работник» и «Зарплата», то таблица «Работник» есть главной, а таблица «Зарплата» есть подчиненной.

9. Какие существуют типы отношений (связей) между таблицами?

Существует 4 основных типа отношений между таблицами:

Пример. Если рассмотреть отношение между таблицами «Работник» и «Зарплата», то это отношения есть типа «один ко многим». Таблица «Работник» есть главной. Таблица «Зарплата» есть подчиненной.

Источник

9) Ключи СУБД

Какие ключи?

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

Пример:

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

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

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

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

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

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

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

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

Пример:

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

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

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

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

Пример:

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

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

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

Пример:

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

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

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

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

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

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

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

Пример:

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

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

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

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

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

Пример:

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

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

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

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

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

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

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

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

Источник

Про uuid-ы, первичные ключи и базы данных

Статья посвящена альтернативным версиям Qt-драйверов для работы с базами данных. По большому счету отличий от нативных Qt-драйверов не так много, всего пара: 1) Поддержка типа UUID; 2) Работа с сущностью «Транзакция» как с самостоятельным объектом. Но эти отличия привели к существенному пересмотру кодовой реализации исходных Qt-решений и изменили подход к написанию рабочего кода.

Первичный ключ: UUID или Integer?

Впервые с идеей использовать UUID в качестве первичного ключа я познакомился в 2003 году, работая в команде дельфистов. Мы разрабатывали программу для автоматизации технологических процессов на производстве. СУБД в проекте отводилась существенная роль. На тот момент это была FireBird версии 1.5. По мере усложнения проекта появились трудности с использованием целочисленных идентификаторов в качестве первичных ключей. Опишу пару сложностей:

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

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

Использование UUID-ов в качестве первичных ключей сводило к минимуму архитектурную проблему, и полностью решало программную. UUID-ключ генерировался перед началом вставки записи на стороне программы, а не в недрах сервера БД, таким образом дополнительный SELECT-запрос стал не нужен, и требование единой транзакции утратило актуальность. FireBird версии 1.5 не имел нативной поддержки UUID-ов, поэтому использовались строковые поля длинной в 32 символа (дефисы из UUID-ов удалялись). Факт использования строковых полей в качестве первичных ключей нисколько не смущал, нам не терпелось опробовать новый подход при работе с данными.

У UUID-ов есть свои минусы: 1) Существенный объем; 2) Более низкая скорость работы по сравнению с целочисленными идентификаторами. В рамках проекта достоинства оказались более значимы, чем указанные недостатки. В целом, опыт оказался положительным, поэтому в последующих решениях при создании реляционных связей предпочтение отдавалось именно UUID-ам.

Примечание: Более подробный анализ UUID vs Integer для СУБД MS SQL можно посмотреть в статье «Первичный ключ – GUID или автоинкремент?»

Первый драйвер для FireBird

В 2012 году мне снова довелось поработать с FireBird. Нужно было создать небольшую программу по анализу данных. Разработка велась с использованием QtFramework. Примерно в это же время у FireBird вышла версия 2.5 с нативной поддержкой UUID-ов. Я подумал: «Почему бы не добавить в Qt-драйвер для FireBird поддержку типа QUuid?» Так появилась первая версия Qt-драйвера с поддержкой UUID-ов. Этот вариант не сильно отличался от оригинальной версии драйвера и, в основном, был ориентирован на использование в однопоточных приложениях.

Появление сущности «Транзакция»

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

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

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

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

В примере экземпляры транзакций (1-3) созданы для наглядности. В рабочем коде их можно опустить. В этом случае транзакции будут создаваться неявно внутри объекта QSqlQuery. Неявные транзакции всегда завершаются ROLLBACK-ом для SELECT-запросов и попыткой COMMIT-а для всех остальных.

Ниже показано как можно использовать одну транзакцию для трех sql-запросов. Подтвердить или откатить транзакцию можно в любой из трех функций.

Драйвер для PostgreSQL

Драйвер для MS SQL

Чего нет в классе Driver

Описываемые здесь драйверы не повторяют один в один функционал Qt-решений. В классе оставлены следующие методы:

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

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

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

Новые функции

Лицензионные ограничения

Зависимости

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

Демо-примеры

Специально для этой статьи был создан демонстрационный проект. Он содержит примеры работы с тремя СУБД: FireBird, PostgreSQL, MS SQL. Репозиторий с драйверами расположен здесь, он подключен в проект как субмодуль. Библиотека SharedTools так же подключена как субмодуль.

Проект создан с использованием QtCreator, сборочная система QBS. Есть четыре сборочных сценария:

Драйвера в первую очередь разрабатывались для работы в Linux, поэтому эксплуатационное тестирование выполнялось именно для этой ОС. В Windows будет работать FireBird-драйвер (проверено), для остальных драйверов тестирование не проводилось.

Демо-примеры записывают следующие логи:

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

Заключение

Черновой вариант статьи не предполагал наличие этого раздела, за что старый товарищ и, по совместительству, корректор подверг меня критике: «Мол, непонятна мотивация, целеполагание неясно. Зачем ты вообще писал эту статью?!» Что ж, исправляюсь!

Источник