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