Преобразование сущностей и отношений

На первом этапе процесса физического проектирования выполняется преобразование ER-диаграмм в реляционные таблицы. Таблицы создаются на основании различных групп или типов подлежащей помещению в базу данных информации. Например, для размещения информации о членах организации может быть создана таблица под названием “Люди” (People), для отслеживания членских взносов — таблица под названием “Взносы” (Payments) и т.д.

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

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

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

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

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

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

Предположим, что есть две таблицы — таблица сотрудников (Employees) и таблица отделов (Departments) — и простое требование, чтобы каждый сотрудник был обязательно членом какого-нибудь отдела. Одним из способов гарантировать это является выполнение проверки на предмет того, чтобы у всех сотрудников в таблице сотрудников был столбец отдела (Department). Представим, что в таблице отделов роль первичного ключа выполняет столбец идентификатора отдела (Department ID), тогда это значит, что необходимо сделать так, чтобы он присутствовал и в таблице сотрудников. Не следует забывать, что у таблицы сотрудников при этом будет свой собственный первичный ключ, вроде номера карточки социального страхования (SSN). Значения столбца идентификатора отдела из таблицы сотрудников, однако, все равно должны все присутствовать в таблице отделов.

Таким образом, получается, что столбец идентификатора отдела (Department ID) из таблицы сотрудников (Employees) будет являться первичным ключом в таблице отделов (Departments), но называться внешним ключом (foreign key) в таблице сотрудников (Employees). Внешние ключи гарантируют то, что в таблицы будут вводиться только действительные данные.

Вас заинтересует / Intresting for you:

Внешние ключи и связи в базе д...
Внешние ключи и связи в базе д... 9487 просмотров MashaSvetlova Sun, 09 Sep 2018, 16:15:48
Хранилище "Ключ - значение": к...
Хранилище "Ключ - значение": к... 2670 просмотров Игорь Воронов Tue, 16 Feb 2021, 13:01:54
Первичные и прочие ключи в баз...
Первичные и прочие ключи в баз... 23063 просмотров MashaSvetlova Sun, 09 Sep 2018, 11:32:06
Оптимизация структур баз данны...
Оптимизация структур баз данны... 1659 просмотров Ирина Светлова Sun, 24 Mar 2019, 06:25:41
Войдите чтобы комментировать