таковой по умолчанию, поэтому любой пользователь может обращаться к этой таблице просто как к МуТаЫе.

Следует отметить, что пользователи с учетной записью sa (или представители роли sysadmin) всегда связаны псевдонимами с ролью dbo. Это означает, что пользователь sa всегда имеет полный доступ к любой базе данных (независимо от того, кто фактически является владельцем базы данных), как если бы он имел роль dbo применительно к этой базе данньгх, а любые объекты, созданные после регистрации в учетной записи sa, показывают, что по своей принадлежности они относятся к роли dbo. С другой стороны, объекты, созданные представителями роли базы данных db owner, не попадают по умолчанию во владение роли dbo, рассматриваемой как название схемы, применяемой по умолчанию; такие объекты присваиваются той схеме, которая определена как применяемая по умолчанию для данного, конкретного пользователя (таковым может быть любой пользователь). В это трудно поверить, но дела обстоят именно так!

Имя базы данных

Следующим компонентом в полностью уточненном имени таблицы, пред)смот-ренным соглашением об именовании, является имя базы данных. Дело в том, что иногда возникает необходимость осуществлять выборку данных из базы данных, отличной от применяемой по умолчанию, или текущей базы данных. Кроме того, может действительно потребоваться применять операцию соединения к данным, хранящимся в разных базах данных. Такая возможность предоставляется благодаря использованию имен таблиц, уточненных именем базы данных. Например, если пользователь зарегистрировался и указал AdventureWorks в качестве текущей базы данньгх, но ему требуется также обратиться к таблице Orders в базе данных Northwind, то он имеет возможность )тсазать имя требуемой таблицы в формате Northwind.dbo.Orders. К тому же схема dbo применяется по туюлчанию, поэтому для обозначения этой таблицы можно использовать имя Northwind. .Orders. Итак, еслрх таблица MyTable базы данных MyData-base принадлежит схеме MySchema, то имя этой таблицы можно указать как MyData-base .MySchema .MyTable. Напомним, что текущая база данных (определенная с помощью команды USE или указанная в раскрывающемся списке, если используется программа SQL Server Management Console) всегда является применяемой по умолчанию, поэтому, если требуются только данные из текущей базы данных, то нет необходимости включать имя базы данных в полностью уточненное имя таблицы.

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

Уточнение имен объектов с использованием имени сервера

в имени таблицы можно не только указывать другую базу данных, отличную от те-к\тцей, на сервере, к котором) подключен пользователь, но и устанавливать так называемую связь с другим сервером. Установление связи с другими серверами дает возможность применять операцию соединения к данным, хранящимся на разных серверах одного и того же типа и даже на серверах разных типов (SQL Sender, Oracle, DB2, Access и т.д.), а при использовании провайдера OLE DB - на серверах практическрх любых типов. Создание связей между серверами в большей степени относится к сфере деятельности администраторов баз данных, а разработчикам достаточно лишь учитывать, что имя сервера создает еще один )ровень в иерархии именования, позволяющий получать дост)т1 к различным серверам, но во всем прочем этот уровень действует во многом аналогично тому, как действуют уровни, представляющие базу данных и владельца.

Теперь вернемся к рассмотрению приведенного выше примера, но в расширенном варианте. Если требуется осуществить выборку информации с сервера, для которого создана связь, называемая MyServer, из таблицы МуТаЫе базы данных MyDatabase, принадлежащей схеме MySchema, то полностью уточненное имя таблицы принимает вид MyServer.MyDatabase.MySchema.MyTable.

Оператор create

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

Рассмотрим полную структуру оператора CREATE, начиная с его наиболее обобщенной формы. Эта форма одинаково присуща операторам CREATE, предназначенным для создания всевозможных объектов базы данных, а различия обнаруживаются только в деталях. Первая часть оператора CREATE всегда выглядит таким образом: CREATE <object type> <object name>

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

Оператор create database

Наиболее простая синтаксическая форма оператора CREATE DATABASE выглядит, как в приведенном ниже примере.

CREATE DATABASE <database name>

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

Необходимо также указать, что оператор CREATE может использоваться только для создания объектов базы данных на локальном сервере (попытка указать конкретное имя сервера оканчивается неудачей).

Если оператор CREATE используется в приведенной выше форме, это приводит к созданию базы данных, полностью аналогичной базе данных model (напомним, что база данных model рассматривалась в главе 1). Тем не менее в действительности всегда требуется ввести какие-либо дополнительные уточнения, касающиеся структуры базы данных. Для этой цели применяется полный синтаксис оператора CREATE DATABASE:

CREATE DATABASE <database name> [ON [PRIMARY]

([NAME = < logical file name>,] FILENAME = <file name>

[, SIZE = <size in kilobytes, megabytes, gigabytes, or terrabytes>] [, MAXSIZE = size in kilobytes, megabytes, gigabytes, or terrabytes>] [, FILEGROWTH = <kilobytes, megabytes, gigabytes, or terrabytespercentage>] ) ] [LOG ON

([NAME = <logical file name>,] FILENAME = <file name>

[, SIZE = <size in kilobytes, megabytes, gigabytes, or terrabytes>] [, MAXSIZE = size in kilobytes, megabytes, gigabytes, or terrabytes>] [, FILEGROWTH = <kilobytes, megabytes, gigabytes, or terrabytespercentage>] ) ] [ COLLATE <collation name> ]

[ FOR ATTACH [WITH <service broker>] FOR ATTACH REBUILD LOG WITH DB CHAINING

{ ON I OFF } I TRUSTWORTHY { ONOFF }]

[AS SNAPSHOT OF <source database name>] [;]

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

Ключевое слово on

ЬСлючевое слово ON используется в двух местах: во-первых, с его помощью определяется местонахождение файла, в котором хранятся данные, и, во-вторых, определяется аналогичная информация, касающаяся места хранения журнала. Важно отметить, что в первом случае указано также ключевое слово PRIMARY, которое означает, что за ним следует первичная (или основная) файловая группа, предназначенная для физического хранения данных. Для хранения данных можно также предусмотреть использование так называемых вторичных файловых групп, но описание их применения выходит за рамки настоящей книги. Однако на данный момент достаточно придерживаться такой предусмотренной по умолчанию структуры базы данных, в которой вся необходимая информация хранится в одном файле.

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