3.2. Роли в sql Server
Роли — это средство объединения учетных записей в группы с целью упрощения администрирования. Включив учетную запись в ту или иную роль сервера, можно предоставить ей определенный набор прав по администрированию сервера и доступа к базе данных.
Роли SQL Server делятся на три группы:
фиксированные серверные роли;
фиксированные роли в базах данных;
пользовательские роли в базах данных.
Ни одну из фиксированных ролей нельзя удалить.
В SQL Server определено восемь фиксированных серверных ролей. Каждой из них назначены разрешения, позволяющие выполнять определенные действия на уровне сервера: управлять учетными записями, создавать базы данных и т.д. Разрешения фиксированной серверной роли нельзя изменить; невозможно также создать новую серверную роль. Если учетная запись принадлежит некоторой роли, она имеет все ее разрешения.
Далее приведены фиксированные серверные роли.
Bulkadmin – выполняет инструкции BULK INSERT.
Dbcreator – создает и модифицирует базу данных.
Diskadmin – управляет дисковыми файлами.
Processadmin – управляет процессами SQL Server.
Securityadmin – администрирует объекты login.
Serveradmin – настраивает опции сервера.
Setupadmin – настраивает репликацию и управляет расширенными процедурами.
Sysadmin – выполняет на сервере любые операции.
По умолчанию, В SQL Server используется учетная запись под именем «sa». Она принадлежит фиксированной серверной роли «sysadmin», имеющей доступ ко всем объектам SQL Server.
Роли базы данных позволяют объединять пользователей в одну административную единицу и работать с ней как с обычным пользователем. Правами доступа к объектам базы данных определенной роли, автоматически наделяются все пользователи, включенные в эту роль.
Для каждой базы данных в SQL Server определено по десять фиксированных ролей. Все системные роли в базе данных, за исключением роли public, имеют фиксированные наборы разрешений, которые нельзя изменять.
Фиксированные роли в базе данных следующие:
Db_accessadmin – добавляет новых пользователей базы данных и удалять существующих.
Db_backupoperator – выполняет резервное копирование базы данных.
Db_datareader – читает все данные во всех пользовательских таблицах базы данных.
Db_datawriter – добавляет, обновляет и удаляет данные любых таблиц базы данных.
Db_ddladmin – создает, изменяет и удаляет объекты базы данных
Db_danydatareader – устанавливает запрет на считывание данных, хранящихся в таблице базы данных
Db_danydatawriter – устанавливает запрет на модификацию данных, хранящихся в базе данных
Db_owner – выполняет в базе данных любые операции
Db_securityadmin – управляет всеми разрешениями базы данных
Public – выполняет только те операции, на которые этой роли предоставлены явные разрешения.
В любой базе данных автоматически создаются два пользователя:
dbo (database owner). Это специальный пользователь базы данных, являющийся ее владельцем. Владелец базы данных имеет абсолютные права по ее управлению. Пользователя dbo нельзя удалить. По умолчанию в пользователя dbo отображается учетная запись sa, которой тем самым предоставляются максимальные права в базе данных. Кроме того, все члены роли базы данных db_owner также считаются владельцами базы данных. Пользователь dbo включен в роль db_owner и не может быть удален из нее;
guest. Если учетной записи явно не предоставлен доступ к базе данных, то она автоматически отображается сервером в пользователя guest. С помощью этого пользователя можно предоставлять разрешения на доступ к объектам базы данных, необходимые любому пользователю. Разрешив доступ пользователю guest, вы, тем самым, даете аналогичные права доступа всем учетным записям, сконфигурированным на SQL Server 2000. Для повышения безопасности хранящейся информации рекомендуется удалять пользователя guest из базы данных.
Владелец базы данных или авторизированный пользователь может создавать пользовательские роли и назначать этим ролям разрешения на доступ к объектам, а также на выполнение инструкций. Каждый новый пользователь базы данных автоматически становится членом системной роли public. Пользовательские роли в базах данных могут быть вложенными.
Каждой роли устанавливаются определенные права на доступ к объектам базы данных. Объектами являются таблицы, столбцы таблиц, представления, хранимые процедуры. Таким образом, контролируется возможность выполнения пользователем команд SELECT, INSERT, UPDATE, DELETE для таблиц и представлений, и команды EXECUTE для хранимых процедур.
What’s dbo?
Don’t you hate it how certain words (well, acronyms in this case) get reused to mean multiple things? dbo seems to cause a great deal of confusion because of this.
First, dbo is an acronym standing for DataBase Owner. And there are three common usages for that I can think of off the top of my head. Feel free to point out others in the comments below and I’ll add them to the list ��
The actual owner of the database.
When talking about permissions this is the actual dbo. There is only one and they can’t be denied and they can do pretty much anything they want in the database.
Members of/have the permissions of the db_owner role.
“She’s dbo.” “He’s a member of dbo.” etc. This is a colloquial use of the term and isn’t technically accurate. The database owner (dbo) is not quite the same as the role db_owner. I generally prefer the more accurate terms (db_owner over dbo) but even I make mistakes here sometimes.
These first two are really not all that different. I’ve seen it create a little bit of confusion every now and again but not often and not much.
The schema.
This is where people start having difficulties. The schema dbo is the most commonly seen usage but it does not have anything to do with permissions. Schemas are containers that hold the objects within a database. They are third part of a fully defined four-part name (InstanceName.DatabaseName.SchemaName.ObjectName). The dbo schema is no different from the schema Sales. Well, other than the fact that most objects in almost every database are put in the dbo schema and I rarely see the Sales schema outside of AdventureWorks databases. Effectively though, they are both just schemas. The owner of the dbo schema has a lot of power, but only because so many objects are in that schema. If you create a database with a schema named Sales and put all of the objects under that schema rather than dbo then the owner of Sales has more power than the owner of dbo.
Obviously the difference between the permissions dbo and the schema dbo is pretty significant. In the end, you’ll have to use context to figure out which dbo you are working with, and if you aren’t sure then you need to look closer and/or ask questions.
What is dbo in SQL Server?
I used to learn about SQL, especially MySQL. Then now my job requires me to understand Microsoft SQL Server (mssql). So I make these notes to guide me and others who want to transition to mssql. I usually summarized what I found and understood so far from browsing the internet.
dbo stands for DataBase Owner.
We can’t remove privileges from an object owner and we can’t drop users from a database if they own objects in it.
schema is a named container for database objects, which allows us to group objects into separate namespaces. The schema is the database object that owns the table. For example, the AdventureWorks sample database contains schemas for Production, Sales, and HumanResources.
The four-part naming syntax for referring to objects specifies the schema name.
Exit fullscreen mode
Schemas can be owned by any database principal and a single principal can own multiple schemas. Principals are entities that can request SQL Server resources.
Schemas that contain objects cannot be dropped. The following schemas cannot be dropped: dbo , guest , sys , INFORMATION_SCHEMA .
The sys and INFORMATION_SCHEMA schemas are reserved for system objects. We cannot create objects in these schemas and we cannot drop them.
The dbo schema is the default schema of every database for all users. By default, users created with the CREATE USER Transact-SQL command have dbo as their default schema. The dbo schema is owned by the dbo user account.
For example, the name of a table called orders owned by dbo is dbo.orders . If the table’s ownership is transferred to user abc , the table will now be named abc.orders .
Users who are assigned the dbo as default schema don’t inherit the permissions of the dbo user account. No permissions are inherited from a schema by users; schema permissions are inherited by the database objects contained in the schema.
the dbo user account is not the same as the db_owner fixed database role and the db_owner fixed database role is not the same as the user account that is recorded as the owner of the database.
The default schema for a user is solely used for object-reference in case the user omits the schema when querying objects. Users in the database will be able to access any object owned by dbo without specifying the owner as long as the user has appropriate permission.
Why do table names in SQL Server start with "dbo"?
At least on my local instance, when I create tables, they are all prefixed with «dbo.». Why is that?
6 Answers 6
dbo is the default schema in SQL Server. You can create your own schemas to allow you to better manage your object namespace.
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):
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.
It’s new to SQL 2005 and offers a simplified way to group objects, especially for the purpose of securing the objects in that «group».
The following link offers a more in depth explanation as to what it is, why we would use it:
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:
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 :
For historical reasons, if you write a user defined scalar function, you will need to call it with the schema prefix:
This does not apply to other objects, such as table functions, procedures and views.
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.