в любой таблице (такой как таблица с заказами, Orders), которая определена как ссылающаяся на таблицу Credit Card, такой столбец, который согласуется со столбцом CreditCardID таблицы CreditCard. Каждая строка, которую мы вставляем в ссьыающуюся таблицу, должна иметь значение, которое находится в нашем списке домена. (Иными словами, этому значению должна соответствовать одна из строк в таблице CreditCard.)

Дополнительная информация по этой теме будет приведена при описании ограничений FOREIGN KEY ниже в данной главе.

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

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

Все возможные виды ограничений, рассматриваемые в настоящей главе, должны быть обозначены именем, но разработчик не обязан сам задавать такое имя. Иными словами, всегда можно воспользоваться тем, что СУБД SQL Server предоставляет имя для того ограничения, для которого имя не было предусмотрено разработчиком. Но этого не следует делать. Дело в том, что имя, сформированное СУБД SQL Server, не всегда подходит для повседневного использования.

В качестве примера можно указать, что имена, формируемые системой, принимают примерно такой вид: PK CustomersCustomers 145C0A3F. В данном случае показано имя, сформированное СУБД SQL Sen ег ддя первичного ключа таблицы Customers -Customers базы данных Accounting. Информация о том, как обновить базу данных Accounting (уничтожить ее вариант, рассматривавшийся в предьщущей главе, и создать новый), приведена ниже в данной главе. В этом примере имени, сформированного системой, РК сокращенно обозначает первичный ключ, primary key (и это - один из компонентов имени ограничения, который следует предусматривать в любом сл-чае). Часть имени ограничения Customers )тсазывает на таблиц) Customers, к которой относится это ограничение, а остальная часть имени - это значение, сформированное случайным образом для обеспечения уникальности ограничения. Для разработчика применять такой способ именования имеет смысл, только если он создает первичные ключи с помощью сценария. А в том случае, если бы для создания этой таблицы использовалась программа Management Studio, то ограничение получило бы имя PK Custoraers.

Но основной недостаток имен, сформированных системой, состоит не в pix сложности, а в том, что эти имена не раскрывают qTH применяемых ограничений; например, как показано ниже в данной главе, при использовании ограничения CHECK системой

формируется имя, напоминающее нечто вроде СК Customers 22АА2996. По этому

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

На одной таблице может быть задано несколько ограничений CHECK, поэтому может оказаться так, что все сформированные системой имена ограничений становятся почти неотличимыми друг от друга (если не учитывать входящие в их состав псевдослучайные числа), как показано в следующем примере:

СК Customers 2 2АА2 996

СК Customers 2 586 9641

СК Customers 2 б 7АВА7А

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

Сам автор стремится явно задавать имя для каждого ограничения и, подготавливая такое имя, задает сокращенное обозначение типа ограничения, а затем либо применяет краткую формулировку назначения этого ограничения, либо указывает имя (имена) столбца (столбцов), на который распространяется данное ограничение. Например, для ограничения, гарантирующего, чтобы пользователи приложения не продавали товары с убытком, по цене ниже стоимости, может быть задано ограничение с именем CKPriceExceedsCost, а для столбца, в котором должно быть обеспечено наличие телефонных номеров, отформатированных должным образом, может быть достаточно применить такое простое имя, KaKCKCustomerPhoneNo.

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

Соблюдение единообразного способа именования.

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

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

И еще раз подчеркнем необходимость соблюдения единообразия имен.

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

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

Инверсные клточи по существу представляют собой любые индексы, которые не налагают на таблицу ограничения в той или иной форме (т.е. ограничения первичного ключа, внешнего ключа или ограничения уникальности). (Информация об индексах будет приведена в главе 8.) Инверсные ключи служат не для принудительного применения средств обеспечения целостности данных, а просто предоставляют альтернативный способ сортировки данных.

Понятие ключей относится к основополагающим понятиям проектирования и управления базой данных, поэтому относится также к числу наиболее важных концепций, представленных в данной книге. Основные сведения по этой теме приведены в предыдущей книге автора. Программирование баз Microsoft SQL Server 2005. Базовый курс, поэтому можно надеяться, что читатели, которые с ней ознакомились, уже обладают необходимыми знаниями, но следует подчеркнуть, что ключи - это одно из самых значимых понятий, без овладения которым невозможно обойтись при изучении темы проектирования, которая рассматривается в главе 7.

Ограничения целостности primary key

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

В базах данных, которые эксплуатировались в среде мэйнфреймов в 1980-х и в начале 1990-х годов, а также в базах данных ISAM (dBase, FoxPro, Clipper и т.д.) применялся совершенно другой подход. В подобной среде одновременно рассматривается только одна строка. Работа с такой базой данных обычно заключается в том, что открывается вся тлблица и последовательно просматриваются ее строки до тех пор, пока не обнаружиоа-етея искомая. Если затем оказывается, что нужно получить данные еще из одной пиибли-цы, отдельно открывается эта таблица и осуществляется выборка данных из таблицы. А в конечном итоге для офаботки завиеимых друг от друга данных применяетея программа.

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

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

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

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