Основные ключи, которые делают управление базой данных простым

Ключи базы данных – это самый простой способ создать реляционную базу данных.

Как вы, возможно, уже знаете, базы данных используют таблицы для организации информации. (Если у вас нет базовых знаний о понятиях базы данных, прочтите «Что такое база данных?»). Каждая таблица состоит из ряда строк, каждая из которых соответствует отдельной записи в базе данных. Итак, как базы данных хранят все эти записи прямо? Это через использование ключей.

Основные ключи

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

Например, предположим, что у нас есть таблица «Сотрудники», которая содержит информацию о персонале для каждого сотрудника нашей фирмы. Нам нужно выбрать подходящий первичный ключ, который бы однозначно идентифицировал каждого сотрудника. Вашей первой мыслью может быть использование имени сотрудника. Это не очень хорошо сработает, потому что вы можете нанять двух сотрудников с одинаковыми именами. Лучшим вариантом может быть использование уникального идентификационного номера сотрудника, который вы назначаете каждому сотруднику при приеме на работу. Некоторые организации предпочитают использовать номера социального страхования (или аналогичные государственные идентификаторы) для этой задачи, потому что у каждого сотрудника уже есть такой номер, и они гарантированно будут уникальными. Однако, использование номера социального обеспечения для этой цели является весьма спорным из-за соображения конфиденциальности. (Если вы работаете в государственной организации, использование номера социального страхования может быть даже незаконным в соответствии с Законом о конфиденциальности 1974 года.) По этой причине большинство организаций перешли на использование уникальных идентификаторов (идентификатор сотрудника, идентификатор студента и т. Д.). .) которые не разделяют эти проблемы конфиденциальности.

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

Большинство баз данных также способны генерировать свои собственные первичные ключи. Например, Microsoft Access может быть настроен на использование типа данных AutoNumber для назначения уникального идентификатора каждой записи в таблице. Несмотря на эффективность, это плохая практика проектирования, поскольку она оставляет бессмысленное значение в каждой записи таблицы. Почему бы не использовать это пространство для хранения чего-то полезного?

Иностранные ключи

Другой тип – это внешний ключ, который используется для создания связей между таблицами. Естественные отношения существуют между таблицами в большинстве структур базы данных. Возвращаясь к нашей базе данных сотрудников, представьте, что мы хотим добавить в базу данных таблицу с информацией об отделах. Эта новая таблица может называться «Отделы» и будет содержать большое количество информации об отделе в целом. Мы также хотели бы включить информацию о сотрудниках в отделе, но было бы излишним иметь одну и ту же информацию в двух таблицах (сотрудники и отделы). Вместо этого мы можем создать связь между двумя таблицами.

Предположим, что в таблице «Отделы» в качестве первичного ключа используется столбец «Имя отдела». Чтобы создать связь между двумя таблицами, мы добавляем новый столбец в таблицу Employees с именем Department. Затем мы заполняем название отдела, к которому принадлежит каждый сотрудник. Мы также информируем систему управления базами данных, что столбец Отдел в таблице «Сотрудники» является внешним ключом, который ссылается на таблицу «Отделы». Затем база данных будет обеспечивать ссылочную целостность, гарантируя, что все значения в столбце «Отделы» таблицы «Сотрудники» имеют соответствующие записи в таблице «Отделы».

Обратите внимание, что для внешнего ключа нет ограничения уникальности. У нас может (и, скорее всего, есть) более одного сотрудника, принадлежащего одному отделу. Точно так же не требуется, чтобы запись в таблице «Отделы» содержала соответствующую запись в таблице «Сотрудники». Возможно, у нас был бы отдел без сотрудников.

Оцените статью
Solutics.ru
Добавить комментарий