Что такое dbo в ms sql

Владение и разделение пользователей и схем в SQL Server

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

Разделение схемы пользователей

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

Четырехкомпонентный синтаксис ссылок на объекты указывает имя схемы.

Server.Database.DatabaseSchema.DatabaseObject

Владельцы схем и разрешения

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

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

Встроенные схемы для обратной совместимости

В состав SQL Server входят девять предварительно определенных схем, имена которых совпадают с именами встроенных пользователей и ролей базы данных: db_accessadmin, db_backupoperator, db_datareader, db_datawriter, db_ddladmin, db_denydatareader, db_denydatawriter, db_owner, db_securityadmin. Они существуют ради обратной совместимости. Рекомендуется не использовать их для объектов-пользователей. Схемы, имеющие те же имена, что и предопределенные роли базы данных, можно удалить, если они еще не используются. В этом случае команда drop просто возвратит ошибку и заблокирует удаление используемой схемы.

IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_accessadmin') DROP SCHEMA [db_accessadmin] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_backupoperator') DROP SCHEMA [db_backupoperator] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_datareader') DROP SCHEMA [db_datareader] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_datawriter') DROP SCHEMA [db_datawriter] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_ddladmin') DROP SCHEMA [db_ddladmin] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_denydatareader') DROP SCHEMA [db_denydatareader] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_denydatawriter') DROP SCHEMA [db_denydatawriter] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_owner') DROP SCHEMA [db_owner] GO IF EXISTS (SELECT * FROM sys.schemas WHERE name = N'db_securityadmin') DROP SCHEMA [db_securityadmin] GO

Если эти схемы удалить из шаблона базы данных, они не появятся в новых базах данных. Схемы, содержащие объекты, не могут быть удалены.

Невозможно удалить следующие схемы:

Схемы sys и INFORMATION_SCHEMA зарезервированы для системных объектов. В этих схемах нельзя создавать и удалять объекты.

Схема dbo

Схема dbo является схемой по умолчанию для каждой базы данных. Схемой по умолчанию для пользователей, созданных с помощью команды Transact-SQL CREATE USER, является dbo . Владельцем схемы dbo является учетная запись пользователя dbo .

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

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

Внешние ресурсы

Дополнительные сведения о принадлежности объектов и схемах см. в следующих документах.

Ресурс	Description
Отделение пользователей от схем	Описывает изменения, возникшие из-за отделения пользователей от схем. Сюда входит новое поведение, его влияние на владение, представления каталогов и разрешения.

См. также

Защита интеллектуальной собственности SQL Server
Приступая к работе с разрешениями Database Engine
Роли уровня сервера
Защита приложений ADO.NET

Субъекты (компонент Database Engine)

Субъекты — это сущности , которые могут запрашивать ресурсы SQL Server. Как и другие компоненты модели авторизации SQL Server, субъекты могут быть организованы в иерархии. Область влияния субъекта зависит от его области определения (Windows, сервер, база данных) и того, неделимый это субъект или коллективный. Имя входа Windows является примером индивидуального (неделимого) субъекта, а группа Windows — коллективного. Каждый субъект имеет идентификатор безопасности (SID). Этот раздел относится ко всем версиям SQL Server, но в База данных SQL или Azure Synapse Analytics существуют некоторые ограничения на уровне сервера.

Идентификатор Microsoft Entra — это новое имя Azure Active Directory (Azure AD). В настоящее время мы обновляем документацию.

Субъекты уровня SQL Server:

Имя входа проверки подлинности SQL Server
имя входа для проверки подлинности Windows для пользователя Windows;
имя входа для проверки подлинности Windows для группы Windows;
Имя входа проверки подлинности Microsoft Entra для пользователя Microsoft Entra
Имя входа проверки подлинности Microsoft Entra для группы Microsoft Entra
Роль сервера

Субъекты уровня базы данных

Пользователь базы данных (существует 12 типов пользователей. Дополнительные сведения см. в разделе CREATE USER.)
Роль базы данных
Роль приложения

Имя входа SA

Имя входа SQL Server sa — это субъект уровня сервера. По умолчанию оно создается при установке экземпляра. Начиная с SQL Server 2005 (9.x), база данных sa по умолчанию является главной. Это изменение поведения с более ранних версий SQL Server. Имя входа sa является участником предопределенной роли сервера sysadmin . sa имеет все разрешения на сервере и не может быть ограничено. Имя входа sa нельзя удалить, но его можно отключить, чтобы никто не смог его использовать.

Пользователь и схема dbo

Пользователь dbo — это особый субъект-пользователя, содержащийся в любой базе данных. Все администраторы SQL Server, участники предопределенной роли сервера sysadmin , имя входа sa и владельцы баз данных подключаются к базам данных в качестве пользователя dbo . Пользователь dbo имеет все разрешения в базе данных и не может быть ограничен или удален. dbo означает владельца базы данных, но учетная запись пользователя dbo не совпадает с предопределенной ролью базы данных db_owner , а предопределенная роль базы данных db_owner не соответствует учетной записи пользователя, помеченной как владелец базы данных.
Пользователь dbo является владельцем схемы dbo . Если не указана другая схема, то схема dbo является схемой по умолчанию для всех пользователей. Схема dbo не может быть удалена.

Роль сервера public и роль базы данных

Каждое имя входа принадлежит к предопределенной роли сервера public , а каждый пользователь базы данных является участником роли базы данных public . Если имени входа или пользователю не были предоставлены или запрещены особые разрешения на доступ к защищаемому объекту, то они наследуют для него разрешения роли public. Предопределенная роль сервера public и предопределенная роль базы данных public не могут быть удалены. Однако можно отменить разрешения для ролей public . Существует множество разрешений, назначенных ролям public по умолчанию. Большая часть этих разрешений необходимы для выполнения повседневных операций в базе данных (операции, которые должен выполнять каждый). Будьте внимательны при отмене разрешения для общедоступного имени входа или пользователя, так как это повлияет на все имена входа и на всех пользователей. Обычно не следует запрещать разрешения для общедоступной роли public, так как инструкция DENY переопределяет любые инструкции GRANT, которые можно выдать для пользователей.

Пользователи и схемы INFORMATION_SCHEMA и sys

Каждая база данных включает в себя две сущности, которые отображены в качестве пользователей в представлениях каталога: INFORMATION_SCHEMA и sys . Они необходимы для внутреннего применения ядром СУБД. Их нельзя изменить или удалить.

Имена входа SQL Server на основе сертификата

Субъекты уровня сервера, имеющие имена, заключенные в хэш-символы (##), — только для внутреннего системного пользования. Следующие субъекты создаются из сертификатов при установке SQL Server и не должны удаляться.

##MS_SQLResourceSigningCertificate##
##MS_SQLReplicationSigningCertificate##
##MS_SQLAuthenticatorCertificate##
##MS_AgentSigningCertificate##
##MS_PolicyEventProcessingLogin##
##MS_PolicySigningCertificate##
##MS_PolicyTsqlExecutionLogin##

В учетных записях субъектов нет паролей, доступных для изменения администраторам, так как они основаны на сертификатах, выданных Майкрософт.

Пользователь-гость

Каждая база данных включает в себя пользователя guest . Разрешения, предоставленные пользователю guest , наследуются пользователями, которые имеют доступ к базе данных, но не обладают учетной записью пользователя в ней. Пользователя guest нельзя удалить, но его можно отключить, если отменить его разрешение CONNECT. Разрешение CONNECT можно отменить, выполнив инструкцию REVOKE CONNECT FROM GUEST; в любой базе данных, кроме master или tempdb .

Связанные задачи

Сведения о проектировании системы разрешений см. в статье Getting Started with Database Engine Permissions.

В этом разделе приведены следующие разделы, посвященные электронной документации по SQL Server:

Инструкции по управлению именами входа, пользователями и схемами
Роли уровня сервера
Роли уровня базы данных
Роли приложений

Why do table names in SQL Server start with «dbo»?

dbo is the default schema in SQL Server. You can create your own schemas to allow you to better manage your object namespace.

answered Jun 30, 2009 at 6:47
4,857 1 1 gold badge 24 24 silver badges 19 19 bronze badges

As a best practice, I always add the «dbo.» prefix even though it is not necessary. Most of the time in SQL it’s good to be explicit.

Jun 30, 2009 at 13:56

@SurroundedByFish: Probably not a best practice, but I could be wrong as I’m not a SQL expert. stackoverflow.com/a/769639/602245

Jan 20, 2012 at 19:19

This article from a different answer claims that it is in fact a best practice: «The code would not have to use the fully qualified name, though there is a slight performance gain in doing so and is considered a best practice. «

Oct 9, 2012 at 16:33

Also, the answer you linked also recommends including the «dbo.» so that the optimizer doesn’t have to look up the schema.

Oct 9, 2012 at 16:42

dbo is not a good practice. Create your own schema and always use it. dbo exists only a a migration trick so pre-SQL Server 2005 continues to work. Yes, always use a schema for perf. No, not the migration one (e.g. dbo).

Nov 5, 2015 at 22:02

If you are using Sql Server Management Studio, you can create your own schema by browsing to Databases — Your Database — Security — Schemas.

To create one using a script is as easy as (for example):

CREATE SCHEMA [EnterSchemaNameHere] AUTHORIZATION [dbo]

You can use them to logically group your tables, for example by creating a schema for «Financial» information and another for «Personal» data. Your tables would then display as:

Financial.BankAccounts Financial.Transactions Personal.Address

Rather than using the default schema of dbo.

36.7k 15 15 gold badges 89 89 silver badges 149 149 bronze badges
answered Jun 30, 2009 at 6:56
243k 71 71 gold badges 388 388 silver badges 402 402 bronze badges
Do you know if that causes any problem when we use Entity framework?
May 24, 2013 at 2:36

You can use schemas with Entity Framework — even with code first if you like: [Table(«Customer», Schema = «MySchema»)]

May 24, 2013 at 8:36

Does the ‘AUTHORIZATION [dbo]’ grant the same permissions as dbo on the schema, or do I still need to grant permissions to the users?

Apr 3, 2014 at 3:14

Microsoft introduced schema in version 2005. For those who didn’t know about schema, and those who didn’t care, objects were put into a default schema dbo .

dbo stands for DataBase Owner, but that’s not really important.

Think of a schema as you would a folder for files:

You don’t need to refer to the schema if the object is in the same or default schema
You can reference an object in a different schema by using the schema as a prefix, the way you can reference a file in a different folder.
You can’t have two objects with the same name in a single schema, but you can in different schema
Using schema can help you to organise a larger number of objects
Schema can also be assigned to particular users and roles, so you can control access to who can do what.

You can generally access any object from any schema. However, it is possible to control which users have which access to particular schema, so you can use schema in your security model.

Because dbo is the default, you normally don’t need to specify it within a single database:

SELECT * FROM customers; SELECT * FROM dbo.customers;

mean the same thing.

I am inclined to disagree with the notion of always using the dbo. prefix, since the more you clutter your code with unnecessary detail, the harder it is to read and manage.

For the most part, you can ignore the schema. However, the schema will make itself apparent in the following situations:

If you view the tables in either the object navigator or in an external application, such as Microsoft Excel or Access, you will see the dbo. prefix. You can still ignore it.
If you reference a table in another database, you will need its full name in the form database.schema.table :

SELECT * FROM bookshop.dbo.customers;

CREATE FUNCTION tax(@amount DECIMAL(6,2) RETURNS DECIMAL(6,2) AS BEGIN RETURN @amount * 0.1; END; GO SELECT total, dbo.tax(total) FROM pricelist;

You can use schema to overcome naming conflicts. For example, if every user has a personal schema, they can create additional objects without having to fight with other users over the name.