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

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

Триггеры

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

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

Ограничения

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

Схемы

Схемы позволяют создавать промежуточное пространство имен между базой данных и содержащимися в ней объектами. По умолчанию в любой базе данных предусмотрено пространство имен dbo (которое представляет владельца базы данных - database owner). Для каждого пользователя предназначена отдельная схема, применяемая по умолчанию, или стандартная схема; СУБД SQL Server автоматически осуществляет поиск требуемых объектов в стандартной схеме пользователя. Но если искомый объект не находится в пространстве имен, которое рассматривается как стандартное для конкретного пользователя, то ссылка на объект должна осуществляться в форме, состоящей из двух частей, <schema name> . <object name> (<имя схемы>.<имя объекта>).

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

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

Файловые группы

По умолчанию все таблицы и прочие объекты базы данных (кроме журналов) хранятся в отдельных файлах. Каждый файл базы данных входит в состав так называемой основной файловой группы. Тем не менее в СУБД SQL Server обеспечивается применение других способов организации хранения данных.

СУБД SQL Server позволяет определять немногим более 32 ООО вторичных файлов. (Если требуемое количество вторичных файлов превышает указанное значение, то, возможно, проблемы их развертывания будут связаны не только с тем, что этого не позволяет СУБД SQL Sei-ver.) Такие вторичные файлы могут быть добавлены к первичной файловой группе или созданы в составе одной или нескольких вторичных файловых групп. Разумеется, предусмотрено применение только одной первичной файловой группы (которая так и называется- Primary ), но можно также использовать до 255 вторичных файловых групп. Вторичные файловые группы создаются с помощью определенных опций оператора CREATE DATABASE или ALTER DATABASE.

Диаграммы

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

В версии SQL Server 2005 предусмотрено много инструментальных средств проектирования базы данных, которые были в значительной степени доработаны и полностью изменились по сравнению с предыдущими версиями, но все равно количество таких инструментальных средств остается недостаточным. Кроме того, методология создания диаграмм, предусмотренная в этих инструментальных средствах, не соответствует ни одному УЗ общепринятых стандартов формирования ER-диаграмм.

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

На рис. L1 приведена диаграмма, на которой демонстрируется определенная часть из многочисленных таблиц базы данных AdventureWorks. Очевидно, что такая диаграмма не только показывает таблицы, но и описывает многие другие свойства базы

данных (хотя для полного понимания смысла диаграмм требуется их более глубокое изучение). Обратите внимание на крошечные пиктограммы с изображениями ключей и знаков бесконечности. Эти пиктограммы описывают xapaicrep связи между таблицами.

Customer (Sales)

CjstomerlD

ТегтйогуЮ

AccountWumber

CjstomerType

rowguid

ModifiedDete

Contact (Person)

CcntactID NameStyle Title

hitstNare

HiddleName LastName

S(jfPi>;

Em Address

EmailPronnotion

Phone

PasswordHash

Pas£wordSalt

AdditionalContactlnfo

rowguid

ModJfiedDate

Address (Person)

AddressID AddressLinel AddressLiner City ~

StateProvincelD PostalCode

Erowguid

ModiFiedDate

EmpI oyeeAddress (HumanResources)

J\ EmployeelD 9 AddressII>

I rowguid

I ModifiedDate

Employee (HumanResources)

Employee ID WationallDNumber ContactID LoginlD

ManagerlD

Tide

BirthDate Marital5l:atu5 Gender HJreOate SalariedFlag VacationHours SickLeaveMours CurrentFlag rowguid ModfedDate

Puc. 1.1. Определения части таблиц базы данных AdventureWorks