Как вы уже знаете, базы данных используют таблицы для организации информации. (Если вы не знакомы с концепциями баз данных, прочитайте «Что такое база данных?»). Каждая таблица состоит из нескольких строк, каждая из которых соответствует одной записи базы данных. Итак, как базы данных сохраняют все эти записи прямо? Это использование ключей.
Первичные ключи
Первый тип ключа, который мы обсудим, - это первичный ключ. Каждая таблица базы данных должна иметь один или несколько столбцов, обозначенных как первичный ключ. Значение, которое удерживает этот ключ, должно быть уникальным для каждой записи в базе данных.
Например, предположим, что у нас есть таблица под названием «Сотрудники», которая содержит информацию о персонале для каждого сотрудника нашей фирмы. Нам нужно выбрать подходящий первичный ключ, который бы однозначно идентифицировал каждого сотрудника. Ваша первая мысль может заключаться в использовании имени сотрудника. Это было бы не очень хорошо, потому что можно предположить, что вы наняли двух сотрудников с тем же именем. Лучшим выбором может быть использование уникального идентификационного номера сотрудника, который вы назначаете каждому сотруднику, когда они наняты. Некоторые организации предпочитают использовать номера социального страхования (или аналогичные правительственные идентификаторы) для этой задачи, потому что у каждого сотрудника уже есть один, и они гарантированно будут уникальными. Однако использование номеров социальной защиты для этой цели является весьма противоречивым из-за проблем с конфиденциальностью. (Если вы работаете в правительственной организации, использование номера социального страхования может быть даже незаконным в соответствии с Законом о конфиденциальности 1974 года.) По этой причине большинство организаций перешли на использование уникальных идентификаторов (идентификатор сотрудника, идентификатор студента и т. Д. .), которые не разделяют эти проблемы конфиденциальности.
После выбора первичного ключа и настройки базы данных система управления базами данных будет обеспечивать уникальность ключа. Если вы попытаетесь вставить запись в таблицу с первичным ключом, который дублирует существующую запись, вставка не будет выполнена.
Большинство баз данных также способны генерировать собственные первичные ключи. Например, Microsoft Access может быть настроен на использование типа данных AutoNumber для назначения уникального идентификатора каждой записи в таблице. Несмотря на эффективность, это плохая практика проектирования, потому что она оставляет вам бессмысленное значение в каждой записи в таблице. Почему бы не использовать это пространство для хранения чего-нибудь полезного?
Иностранные ключи
Другой тип - это внешний ключ, который используется для создания связей между таблицами. Естественные отношения существуют между таблицами в большинстве структур баз данных. Вернувшись в базу данных наших сотрудников, представьте, что мы хотели добавить в базу данных таблицу, содержащую ведомственную информацию. Эта новая таблица может называться Департаментами и содержать большой объем информации о отделе в целом. Мы также хотели бы включить информацию о сотрудниках в отдел, но было бы излишним иметь ту же информацию в двух таблицах («Сотрудники и департаменты»). Вместо этого мы можем создать взаимосвязь между двумя таблицами.
Предположим, что в таблице отделов в качестве первичного ключа используется столбец «Название отдела». Чтобы создать связь между двумя таблицами, мы добавляем новый столбец в таблицу Employees под названием Department. Затем мы заполняем имя отдела, к которому принадлежит каждый сотрудник. Мы также сообщаем системе управления базами данных, что столбец «Департамент» в таблице «Сотрудники» является внешним ключом, который ссылается на таблицу «Отделы». Затем база данных будет обеспечивать ссылочную целостность, гарантируя, что все значения в столбце «Департаменты» таблицы «Сотрудники» имеют соответствующие записи в таблице «Отделы».
Обратите внимание, что для внешнего ключа нет ограничения уникальности. Мы можем (и, скорее всего, делать) иметь более одного сотрудника, принадлежащего одному отделу. Аналогичным образом, нет требования, чтобы запись в таблице отделов имела соответствующую запись в таблице «Сотрудники». Возможно, у нас будет отдел без сотрудников.
Подробнее об этой теме читайте «Создание внешних ключей».
