На этом шаге мы рассмотрим понятие первичного ключа.
Прежде чем обсудить создание связи между сущностями, мы должны рассмотреть еще одну их особенность. У каждой сущности должен быть первичный ключ или по-другому уникальный идентификатор, который мы будем называть ID. ID есть атрибут сущности, к которому применимы следующие правила:
- он уникален для каждого экземпляра сущности;
- для каждого экземпляра сущности он имеет значение, отличное от пустого (NULL) в течение всего срока существования экземпляра;
- в течение всего времени существования экземпляра его значение не меняется.
То есть иными словами под первичным ключом понимают поле или набор полей, однозначно идентифицирующий запись.
ID очень важен, поскольку позволяет узнать, с каким из экземпляров мы работаем. Выбор идентификатора также существен, потому что он используется для моделирования связей. Если после выбора ID вы обнаружили, что он не удовлетворяет одному из перечисленных правил, это может повлиять на всю вашу модель данных. Рассмотрим понятие первичного ключа на примере таблицы 1.
| № зачетки | Ф.И.О. | Группа | Кол-во задолженностей |
|---|---|---|---|
| 024108 | Емельянов А. В. | 333 | 5 |
| 025485 | Варфаламеев К. Л. | 333 | 2 |
| 026739 | Попов И. Е. | 332 | 2 |
| 028925 | Варфаламеев Б. Г. | 331 | 0 |
В данном примере возникает соблазн выбрать в качестве идентификатора ФИО, поскольку это есть у каждого студента. Но что если человек вступает в брак или законным образом хочет изменить фамилию? Тогда нарушается третье правило для идентификаторов. Еще хуже то, что ФИО окажутся не уникальными, что если два студента полные тезки, вы нарушите первое правило для идентификаторов. Абсолютно бессмысленно использовать в качестве первичного ключа атрибут кол-во задолженностей и группа. В данном случае в качестве первичного ключа может выступать номер зачетки.
Вернемся к нашим CD (шаг 6). При глубоком анализе видно, что ни один из атрибутов не может играть роль идентификатора. Действительно мы видим, что могут существовать два CD одного исполнителя, также разные исполнители дают своим альбомам одинаковые названия. Поле год записи не может быть первичным ключом т.к. в год записываются тысячи пластинок. То есть из примера видно, что ни одно поле не может исполнять роль первичного ключа. Как же поступают в таких ситуациях? В этом случае следует добавить в таблицу семантически незначащее поле, (то есть не имеющего иного смысла, кроме обеспечения уникальности записи), например числовое поле "№" (таблица 2).
| № | Название ансамбля | Название CD | Год записи | Песня |
|---|---|---|---|---|
| 1 | Петлюра | Север | 1999 | Север, В городском саду, Родители, весна, Солдат… |
| 2 | Петлюра | Судьба | 1998 | Мчится карета, Судьба, Солдатка, Цвела акация... |
| 3 | 5`NIZZA | 5`NIZZA | 2003 | Пятница, Тянуться, Ямайка, Солдат… |
| 4 | Nautilus | Наугад | 1998 | Тихие игры, Падал теплый снег, Черные птицы… |
| 5 | Фактор 2 | Девочка Мальвина | 2003 | Одинокая звезда, Окна, Привидение, Hey, Baby, Hey... |
Уникальность подобного поля обычно отслеживается или программно, или автоматически. В первом случае при добавлении нового CD приложение, работающее с базой данных, отыскивает максимальный номер сотрудника, увеличивает его на 1 и назначает вновь добавляемой записи. Во втором случае первичный ключ реализуется через автоинкрементное поле. Для него сказанные действия выполняются автоматически системой управления базой данных.
Поскольку этот атрибут искусственный и никак не связан с сущностью, мы имеем над ним полный контроль и можем обеспечить его соответствие правилам для уникальных идентификаторов. На рисунке 1 к каждой из наших сущностей добавлен искусственный ID. На диаграмме уникальный идентификатор изображается как подчеркнутый атрибут.
Рис.1. Сущности CD и Песня со своими уникальными идентификаторами
При детальном рассмотрении природы первичных ключей рано или поздно возникает вопрос: если в рамках данной предметной области мы можем обойтись без первичного ключа, стоит ли вводить искусственный первичный ключ? На первый взгляд можно и обойтись в некоторых базах данных и без идентификатора. Например, список покупок в котором нужно подсчитать только итоговую сумму. Однако в процессе отладки приложений, работающих с базами данных, при возникновении сбоев, потерь данных, нарушении смысловой целостности всегда нужно знать, с какой именно записью мы имеем дело. Роль уникального идентификатора записи в этом случае трудно переоценить. Поэтому не только правила хорошего тона при разработке структур баз данных, но и чисто практические соображения должны побудить разработчика всегда определять первичный ключ для таблицы базы данных.
На следующем шаге мы рассмотрим реляционные отношения.
