Способы именования ограничений

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

Все возможные виды ограничений должны быть обозначены именем, но разработчик не обязан сам задавать такое имя. Иными словами, всегда можно воспользоваться тем, что СУБД предоставляет имя для того огра­ничения, для которого имя не было предусмотрено разработчиком. Тем не менее следует избегать соблазна воспользоваться такой возможностью, поскольку вскоре обнаруживает­ся, что имена, создаваемые СУБД, не вполне приемлемы.

В качестве примера можно указать, что имена, формируемые системой, прини­мают такой вид: РК__Employees__145C0A3F, в этом примере имени, сформированного системой, РК: «сокращенно обозначает первичный ключ, primary key (и это— один из компонентов имени ограничения, который следует предусматривать в любом случае), часть име­ни ограничения Employees указывает на таблицу Employees, к которой относится это ограничение, а остальная часть имени — это значение, сформированное случайным образом для обеспечения уникальности ограничения. Очевидно, что имя, сформи­рованное системой, не подходит для повседневного использования, поэтому для разработчика имеет смысл применять такой способ именования, только если он создает первичные ключи с помощью сценария. А в том случае, если бы для создания этой таблицы использовалась программа Management Studio, то ограничение получило бы имя PK_Employees.

Но основной недостаток имен, сформированных системой, состоит не в их слож­ности, а в том, что эти имена не раскрывают сути применяемых ограничений; на­пример при использовании ограничения CHECK системой формируется имя, напоминающее нечто вроде СК__Customers__22АА2996.

По этому имени можно определить, что оно относится к ограничению CHECK, одна­ко невозможно что-либо узнать, в чем состоит характер соответствующей проверки CHECK.

Учитывая то, что на одной таблице может быть задано несколько ограничений CHECK, можно понять, что при формировании имен ограничений системой все огра­ничения, заданные на одной и той же таблице, приобретают примерно такие имена:

СК__Customers__22AA2996

СК__Customers__258 69 641

СК__Customers__2 67ABA7A

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

В предыдущих лабораторных работах уже говорилось о том, какими правилами следует руководство­ваться при выборе имен различных объектов, но отметим еще раз, что в действи­тельности не так важен выбор самих имен, как соблюдение перечисленных ниже требований:

- Обеспечение единообразия.

- Применение имен, понятных для всех.

- Применение наиболее краткой формулировки для имен и вместе с тем соблю­дение двух указанных правил.

Ограничения ключей

Ограничения primary key

Первичные ключи представляют собой уникальные идентификаторы для каждой строки. Столбец первичного ключа должен содержать уникальные значения (и по­этому в этом столбце не допускается наличие NULL-значения). Первичные ключи очень важны для нормальной эксплуатации реляционной базы данных, поэтому яв­ляются наиболее фундаментальными объектами базы данных по сравнению со всеми прочими ключами и ограничениями.

Не следует путать первичный ключ, который однозначно идентифицирует каждую строку в таблице, с идентификатором GUID, который является более универсальным средством, как правило, применяемым для идентификации любых объектов (а не просто строк) во вре­мени и пространстве. Безусловно, идентификаторы GUID могут использоваться в качестве первичного ключа, но это связано с некоторыми дополнительными издержками, к тому же обычно в их применении нет особого смысла, если речь идет лишь о том, чтобы предоста­вить пользователю содержимое некоторой таблицы. В действительности необходимость в использовании идентификаторов GUID возникает лишь в том широко известном случае, когда создается среда базы данных с тиражируемыми или иным образом распределенны­ми данными. В подобных случаях невозможно обойтись без применения идентификаторов GUID для создания первичного ключа.

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

Следует подчеркнуть высказанную выше мысль, отметив, что таблицы без первичного клю­ча встречаются не просто редко, а очень редко. Наличие в базе данных таблицы, не имею­щей первичного ключа, полностью противоречит представлениям о реляционном характере данных, хранимых в базе данных, поскольку из этого следует, что возможность установить связь с какой-либо конкретной строкой этой таблицы отсутствует. Данные, представлен­ные в таблице, не имеющей первичного ключа, не имеют также каких-либо отличительных признаков.

Безусловно, нередко встречаются ситуации, в которых многочисленные строки таблицы ло­гически идентичны друг другу, но это не означает, что возможность создания первичного ключа для такой таблицы отсутствует. В подобных обстоятельствах может быть пред­усмотрено искусственное создание ключа того или иного типа. Подобный подход чаще всего реализуется с использованием столбца идентификации, но в некоторых ситуациях в боль­шей степени оправдано применение идентификаторов GUID.

Первичный ключ гарантирует уникальность сочетания значений столбцов, объяв­ленных как принадлежащие к этому первичному ключу. Сами эти уникальные значе­ния служат в качестве идентификаторов для каждой строки в таблице. Для создания первичного ключа по существу применяются два способа. Первичный ключ может быть либо создан с помощью команды CREATE TABLE во время создания таблицы, либо введен в действие впоследствии с помощью команды ALTER TABLE.