На первом этапе процесса физического проектирования выполняется преобразование ER-диаграмм в реляционные таблицы. Таблицы создаются на основании различных групп или типов подлежащей помещению в базу данных информации. Например, для размещения информации о членах организации может быть создана таблица под названием “Люди” (People), для отслеживания членских взносов — таблица под названием “Взносы” (Payments) и т.д.
А как быть, если требуется гарантировать уникальность данных в таблицах (что требуется в большинстве случаев)? И как насчет того, чтобы установить отношения между таблицами, в которых хранится связанная информация? Для обеспечения уникальности и установки действительных отношений в базе данных можно использовать первичные и внешние ключи.
Первичные ключи
Первичным ключом (primary key) называется столбец или комбинация столбцов, которая уникальным образом идентифицирует каждую запись (или строку) в таблице.
В таблицах, где присутствуют записи для различных людей, в качестве первичных ключей принято использовать номер карточки социального страхования, поскольку очевидно, что у каждого человека такой номер является уникальным. Если столбца, подходящего на роль первичного ключа, нет, для уникальной идентификации строк можно использовать номера, генерируемые системой. Первичный ключ должен обязательно быть уникальным и присутствовать в каждой строке таблицы для обеспечения действительности данных.
Выбирать первичные ключи нужно из списка потенциальных ключей для всех таблиц в базе данных. В случае применения какого-то программного обеспечения для моделирования данных, скорее всего, ключи, необходимые для каждой сущности, будут определяться и создаваться автоматически. Команда разработчиков приложения обеспечивает выбор наилучших кандидатов на роль первичных ключей.
Внешние ключи
Предположим, что есть две таблицы — таблица сотрудников (Employees) и таблица отделов (Departments) — и простое требование, чтобы каждый сотрудник был обязательно членом какого-нибудь отдела. Одним из способов гарантировать это является выполнение проверки на предмет того, чтобы у всех сотрудников в таблице сотрудников был столбец отдела (Department). Представим, что в таблице отделов роль первичного ключа выполняет столбец идентификатора отдела (Department ID), тогда это значит, что необходимо сделать так, чтобы он присутствовал и в таблице сотрудников. Не следует забывать, что у таблицы сотрудников при этом будет свой собственный первичный ключ, вроде номера карточки социального страхования (SSN). Значения столбца идентификатора отдела из таблицы сотрудников, однако, все равно должны все присутствовать в таблице отделов.
Таким образом, получается, что столбец идентификатора отдела (Department ID) из таблицы сотрудников (Employees) будет являться первичным ключом в таблице отделов (Departments), но называться внешним ключом (foreign key) в таблице сотрудников (Employees). Внешние ключи гарантируют то, что в таблицы будут вводиться только действительные данные.