Schema
In this usage "Schema" refers to the security context in which an object is accessed. By default the schema is assigned to the user who created the object. The usual default schema, for instance, is dbo [dbo.Database owner]dbo.table1. But if the logged in user who create the table was joe the schema would be joe.table1.
Up until SQL Server 2005 that was the limit to the control over schema, but in SQL 2005 Microsoft separted schema from the objects in a way that allows them to be used as a powerful tool for organizing views and permissions.
Microsoft added the create schema statement
--create a human resourses schema CREATE SCHEMA HR AUTHORIZATION [DBO];
Having created the schema you can create objects that belong to that schema
CREATE VIEW HR.Employees
AS
SELECT SocialSecurityNo, lastname, firstname, Department, hiredate,
payrate
FROM Employees
To see the real power of this though, you must understand it in the context of Logins and Users
Logins, Users
Server Logins
Before you can access an instance of SQL Server you must have a server login. The server login in itself only lets you into SQL server. It does not give you access to any of the server's resources.
There are two kinds of server logins:
- Windows logins
- Windows logins use Windows the authenticate the user. Windows checks the user's id and password against a valid windows account and then that account is mapped to SQL Server. The Windows account must exist before you can make the login. It can be a local machine user account or it can be an Active Directory account. Microsoft suggests using Windows logins where possible.
- SQL Server Logins
- SQL server accounts are authenticated by SQL Server itself.
Here are some examples
--Windows login syntax
USE MASTER
CREATE LOGIN [domain or windowsuser]\{LoginName] FROM WINDOWS
CREATE LOGIN [Student01\Joe] FROM WINDOWS
--Sql Server Logins
USE MASTER
CREATE LOGIN Joe
WITH Password='p@$$w0rd',
default_database=MagazineSubscription
Even the defualt database does not give you access to that database. You must add a "user" for that database who is mapped to an exisiting "Server Login."
Database Users
For a login to have access to a particular database there must be a database user. Now the real power of schema can be seen. When we create the login we can assign to it a default schema and when that user logs into the database, he or she will only see what is in their default schema. Here is the syntax for creating a database user. Assume "Project" is a database that tracks on going projects for a company.
USE Project --create shema and give them database owner permissions CREATE SCHEMA Proj_Managers AUTHORIZATION [DBO] --Now add users CREATE USER mangr FOR LOGIN manager WITH DEFAULT_SCHEMA=Proj_Managers --Give Permissions GRANT SELECT ON SCHEMA::[Proj_Managers] to [mangr] -- now we will create an object that belongs to that schema CREATE VIEW Proj_Managers.CurrentProjects AS SELECT ProjectDate, ProjectName, ProjectDescription FROM Project WHERE ProjectEndDate IS NULL
When the project manager log in to the database they will--at this point--see only the view of current projects.