Имя схемы (известное также как имя владельца)

Если в проекте базы данных используются схемы (в большинстве созданных ранее проектов баз данных это не предусмотрено, но создается впечатление, что в дальнейшем важность применения схем будет неуклонно возрастать), то в процессе работы с объектами базы данных чаш;е всего приходится указывать, в какой схеме они находят ся. Дело в том, что схемы позволяют создавать объекты, имеющие одинаковые имена, но находящиеся в разных схемах. Если пользователь желает получить доступ к объекту, который не находится в схеме этого пользователя, применяемой по умолчанрпо (которая определяется во время регистрации пользователя), то должен конкретно указывать имя схемы, SchemaName, в которой находится объект. Например, рассмотрим вариант применения схем в базе данных AdventureWorks (кстати, это - один из наихудших вариантов организации схем, которые когда-либо встречались автору) и составим запрос на получение списка сотрудников с указанием городов, в которых они проживают:

SELECT е.EmployeelD, с.FirstName, с.LastName, City FROM HumanResources.Employee AS e JOIN Person.Contact с

ON e.ContactID = e.ContactID JOIN HumanResources.EmployeeAddress AS ea

ON e.EmployeelD = ea.EmployeelD JOIN Person.Address AS a

ON ea.AddressID = a.AddressID

В данном примере используются четыре таблицы, распределенные по двум схемам. Если бы оказалось так, что одна из двух рассматриваемых схем (HumanResources или Person) является схемой, применяемой по умолчанию, то можно было бы не задавать имя этой схемы, составляя в запросе имена таблиц, находящихся в схеме. Но в данном случае указаны имена всех схем, поскольку это позволяет избежать любых неприятных сюрпризов.

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

Дополнительные сведения о схемах

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

бы немного другое назначение). Поэтому, в частности, в предыдущих версиях SQL Server то, что принято называть схемой в SQL Server 2005 и других базах данных, таких как Oracle, обычно именовалось владельцем.

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

Разумеется, определенная часть разработчиков всегда с трудом расстается с теми средствами, которые должны быть подвергнуты пересмотру. В качестве примера можно привести использование понятия владельца в версиях, предшествующих SQL Server 2005, но автор, безусловно, не относится к такой категории разработчиков. Важной отличительной особенностью версии SQL Server 2005, о которой всегда следует помнить, является то, что в ней изменР171ась структура имен в связи с отказом от понятия владельца, поэтому та часть базы данных, в которой находятся объекты, принадлежащие определенному пользователю, теперь обозначается термином схема , более совместимым со стандартом ANSL Такое изменение подхода следует учитывать не только потому, что компания Microsoft стала на путь перехода от использования понятия владельца к применению понятия схемы, но и в связи с тем, что работа в этом направлении продолжается, а это означает, что в будущих npoeicrax отказ от использования схем станет уже невозможным. В версии SQL Server 2005 предусмотрены новые функции, обеспечивающие поддержьсу применения схем в структуре имен, и даже новые образцы баз данных, которые входят в поставку этой версии (в том числе база данных AdventureWorks, которая уже встречалась в данной книге время от времени, а в следующих главах будет применяться более часто), характеризуется широким использованием схем. Значимость схем возрастает также в связи с тем, что их применение теперь предусмотрено в таких службах SQL Server, как Notification Services.

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

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

По умолчанию создавать объекты в базе данных имеют право только пользователи, которые относятся к системной роли sysadmin, а также пользователи, относящиеся к таким ролям базы данных, как db owner или db ddladmin.

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

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

Дополнительная информация по этой теме приведена в главе 22, но следует заранее отметить, что СУБД SQL Server предоставляет очень широкие возможности, но использоваться они должны обоснованно! В частности, нельзя назвать иначе, как непродуманным решением предоставление прав на создание объектов базы данных с помощью оператора CREATE всем пользователям. Дело в том, что из-за этого становится буквально невозможно проследить за тем, кто, когда и по какой причине создал тот или иной объект. Короче говоря, следует ограничиваться предоставлением доступа к оператору CREATE либо только учетной записи sa, либо представителям привилегированной роли sysadmins или db owner.

Применяемая по умолчанию схема dbo

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

Например, предположим, что некоторый пользователь повседневно работает с базой данных, имеет регистрационное имя My Schema и обладает правом на создание таблиц, CREATE TABLE, в какойо конкретной базе данных. После создания этим пользователем таблицы MyTable данная таблица получает имя объекта My Schema. MyTable, уточненное именем владельца. Следует учитывать, что рассматриваемая таблица имеет конкретного владельца, поэтому любому отличному от него пользователю (напомним, что речь идет о пользователе MySchema), желающему получить доступ к таблице MySchema .MyTable, придется указывать уточненное имя таблицы, содержащее данные об имени владельца, так как лишь при этом условии СУБД SQL Server сможет распознать имя таблицы.

Теперь предположим, что определен также пользователь с регистрационным именем Fred. Допустим, Fred- владелец базы данных (а не просто один из представителей роли db owner). Если пользователь Fred создаст таблицу MyTable с помощью оператора CREATE, идентичного тому, который применялся пользователем MySchema, то данная таблица приобретет имя, уточненное именем владельца, dbo.MyTable. Кроме того, оказывается, что dbo также является владельцем, рассматриваемым как