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

Чтобы приступить к работе с ограничениями целостности CHECK, относящимися к таблице, щелкните правой кнопкой мыши на таблице и выберите команду Check Constraints. В результате появится диалоговое окно, которое позволяет создать новое ограничение целостности или выбрать одно из тех ограничений, которые уже заданы для рассматриваемой таблицы. После того как будет создано новое ограничение или выбрано одно из существующих, в программе Management Studio откроется диалоговое окно, почти ничем не отличающееся от того, которое предназначено для работы с внешними ключами.

1Сак и при создании таблиц, рядом с именем ограничения, CK CustomerNotes, появится звездочка, которая означает, что в определение ограничения внесены изменения, но не сохранены. В диалоговом окне, предназначенном для работы с ограничениями целостности CHECK, заслуживает внимания то, что кроме полей, показанных на рис. 7.20, имеется поле Expression, в котором необходимо ввести условия, заданные в ограничении целостности.

Кроме того, в диалоговом окне для работы с ограничениями целостности CHECK имеется поле Identity, которое не следует путать с определением стюлбца IDENTITY, поскольку этот раздел диалогового окна предназначен лишь для ввода имени и (в случае необходимости) описания ограничения целостности.

Чтобы отредактировать существующее ограничение целостности, остается лишь внести в его свойства требуемые изменения. Для удаления одного из ограничений целостности CHECK достаточно выбрать требуемое ограничение целостности и щелкнуть на кнопке Delete.

Резюме

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

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

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

Глава 8

Структуры памяти

и индексные структуры

SQL Server

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

В настоящей главе приведено довольно подробное описание индексов с точки зрения разработчика и администратора, но для того, чтобы лучше понять, как действуют индексы, необходимо разобраться в том, как организовано хранение данньгх в СУБД SQL Server. По этой причине в данной главе кратко рассматривается механизм хранения данных СУБД SQL Ser\er, включая внутренние структуры и стратегии распределения индекса, используемые в SQL Ser\er.

Средства хранения данных СУБД SQL Server

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

База данных

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

Блокировка - это объект, одновременно напоминающий замок и маркер места хранения данных, которые используются системой, Больилой объем сведений о блокировках будет приведен в главе 12, а в данной главе возможности задания блокировок на объектах в СУБД SQL Server будут кратко рассматриваться при обсуждении структур памяти.

Файл

По умолчанию с базой данных связаны два файла.

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

Второй из этих файлов, файл журнала, представляет собой своего рода дополнение к файлу базы данных. Журнал будет рассматриваться более подробно при описании транзакций и блокировок в главе 12, но следует учитывать, что журнал всегда занимает отдельный файл (который должен иметь имя с расширением * . Idf) и что база данных не может работать без журнала. Журнал представляет собой результат последовательной регистрации всего того, что происходило с базой данньгх со времени последней фиксации данньгх в базе данных. В действительности база данных почти никогда не содержит весь объем данных, представленных в СУБД. Тем более весь объем данных не содержится в журнале. Все данные становятся доступными пользователю после того, как произойдет запуск базы данных и начнется регистрация в журнале операций, выполняемых с данными, с последующим переносом результатов этих операций в базу данньгх.

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