Информационные системы
Шрифт:
Естественный ключ – это ключ, в который включены значимые атрибуты и который, таким образом, содержит информацию.
Примечание.
В рассматриваемом нами примере в качестве первичного ключа отношения СТУДЕНТЫ можно рассматривать атрибут №_студенческого_билета. Причем данный ключ является естественным, так как несет вполне определенную информацию.
Каждый из типов первичных ключей имеет свои достоинства и недостатки; их обсуждению посвящено большое количество публикаций. Мы не будем проводить подробное их сравнение, а отметим лишь основные плюсы и минусы каждого из видов ключей.
Основными достоинствами
Основным же недостатком естественных ключей является то, что их использование весьма затруднительно в случае изменчивости предметной области. Следует понимать, что значения атрибутов первичного ключа не должны меняться. То есть однажды заданное значение первичного ключа для кортежа не может быть позже изменено. Такое требование ставится в основном для поддержания целостности базы данных. Связь между отношениями обычно устанавливается именно по первичному ключу, и его изменение приведет к нарушению этих связей или к необходимости изменения записей в нескольких таблицах. Даже в сравнительно простых базах данных это может вызвать ряд трудноразрешимых проблем.
Примечание.
В некоторых реляционных СУБД допускается изменение первичного ключа. Иногда это бывает действительно полезно. Однако прибегать к этому следует лишь в случае крайней необходимости.
Типичным примером изменчивой предметной области, в которой для сущности невозможно определить неизменяемый естественный ключ, является любая область с человеком в качестве сущности.
Второй довольно существенный недостаток естественных ключей состоит в том, что, как правило, уникальные естественные ключи являются составными и содержат строковые атрибуты. Как уже отмечалось, максимальная скорость выполнения операций над данными обеспечивается при использовании простых целочисленных ключей. Таким образом, с точки зрения быстродействия системы естественные ключи часто оказываются неоптимальными.
Оба недостатка естественных ключей можно преодолеть, определив в отношениях суррогатные ключи, представляющие собой некоторый универсальный атрибут, как правило, целочисленного типа, не зависящий ни от предметной области, ни, тем более, от структуры отношения, которое он идентифицирует. Таким образом можно обеспечить уникальность и неизменность ключа (раз он никаким образом не зависит от предметной области, то никогда не возникнет необходимость изменять его). Однако за это приходится платить избыточностью данных в таблицах.
Примечание.
Следует заметить, что во многих практических реализациях реляционных СУБД допускается нарушение свойства уникальности кортежей для промежуточных отношений, порождаемых неявно при выполнении запросов. Такие отношения являются не множествами, а мультимножествами, что в ряде случаев позволяет добиться определенных преимуществ, но иногда приводит к серьезным проблемам.
В любой из таблиц может оказаться несколько наборов атрибутов, которые допустимо выбрать в качестве ключа. Такие наборы называются
Нередко в отношениях определяются так называемые вторичные ключи. Вторичный ключ представляет собой комбинацию атрибутов, отличную от комбинации, составляющей первичный ключ. Причем вторичные ключи не обязательно обладают свойством уникальности. При их определении могут задаваться следующие ограничения:
• UNIQUE – ограничение уникальности, значения вторичных ключей при данном ограничении не могут дублироваться;
• NOT NULL – при данном ограничении ни один из атрибутов, входящих в состав вторичного ключа, не может принимать значение NULL
Перекрывающиеся ключи – сложные ключи, которые имеют один или несколько общих столбцов.
Связанные отношения
В реляционной модели данные представляются в виде совокупности взаимосвязанных таблиц. Подобное взаимоотношение между таблицами называется связью (relation). Таким образом, еще одним важным понятием реляционной модели является связь между отношениями.
Для анализа связанных отношений воспользуемся рассмотренным ранее примером – отношением СТУДЕНТЫ (см. табл. 4.1). Данное отношение может быть связано с отношением УСПЕВАЕМОСТЬ, в котором содержатся сведения об успеваемости студентов по разным предметам. Фрагмент такого отношения может выглядеть так, как показано в табл. 4.2.
Таблица 4.2. Фрагмент отношения УСПЕВАЕМОСТЬ, связанного с отношением СТУДЕНТЫ
Атрибут №_студенческого_билета таблицы УСПЕВАЕМОСТЬ содержит идентификатор студента (в данном примере в качестве такого идентификатора используется номер студенческого билета). Если нужно узнать имя студента, соответствующее строкам в таблице УСПЕВАЕМОСТЬ, то следует поискать это же значение идентификатора студента в поле №_студенческого_билета таблицы СТУДЕНТЫ и в найденной строке прочесть значение поля Имя. Таким образом, связь между таблицами СТУДЕНТЫ и УСПЕВАЕМОСТЬ устанавливается по атрибуту №_студенческого_билета.
При рассмотрении связанных таблиц важное значение имеет понятие внешнего ключа. Рассмотрим его более подробно.
Внешние ключи отношения
В базах данных одни и те же имена атрибутов часто используются в разных отношениях. В рассматриваемом примере атрибут №_студенческого_билета присутствует как в отношении СТУДЕНТЫ, так и в отношении УСПЕВАЕМОСТЬ. В этом примере атрибут №_студенческого_билета иллюстрирует понятие внешнего ключа (foreign key).
Внешний ключ – это атрибут (или множество атрибутов) одного отношения, являющийся ключом другого (или того же самого) отношения.
Внешние ключи используются для установления логических связей между отношениями. Связь между двумя таблицами устанавливается путем присваивания значений внешнего ключа одной таблицы значениям ключа другой.
Так же как и любые другие ключи, внешние ключи могут быть простыми либо составными.
Часто связь между отношениями устанавливается по первичному ключу, то есть значениям внешнего ключа одного отношения присваиваются значения первичного ключа другого отношения. Однако это не является обязательным – в общем случае связь может устанавливаться и с помощью вторичных ключей. Кроме того, при установлении связей между таблицами необязательно требование уникальности ключа, по которому устанавливается связь.