This post is part of a series I am writing with an “Introduction to SQL Server” theme. If you are new to SQL Server and want to learn the basics, hopefully, this series will help you. It’s very much a getting-started guide. You will find lots of advanced posts written by lots of community contributors, but if you are completely new, hopefully, this series will get you started and pointed in the right direction.
This post is all about understanding schemas in SQL Server
Understanding Schemas in SQL Server
In our last post, we looked at creating databases in SQL Server. A database is an empty container will allow us to create database objects and store our data. A schema is something in a SQL Server database that will allow us to logically group and organise our various database objects, such as tables, Stored Procs, Triggers, etc. together.
So, with a database created, let’s take two minutes to understand schemas.
What are Schemas in SQL Server?
In SQL Server, a schema is a container found within a database that holds database objects such as tables, views, procedures, and functions. Schemas serve as a way to organise and group these objects within a database together, providing a logical structure that can simplify database management and security. So, let’s say you have a bunch of tables that belong to the sales element of your application. You can group all those sales objects together under the Sales schema.
Uses and benefits of Schemas
Schemas have several purposes.
-
Organisation: Schemas help organise database objects into logical groups. For example, you can have different schemas for different application modules, business areas, or types of data (e.g.,
Sales,ÂHR,ÂFinance). -
Security:Â Schemas allow for fine-grained control over database security. Permissions can be granted or revoked at the schema level, making it easier to manage access to groups of related objects.
-
Namespace Management:Â Schemas provide a way to manage namespaces in the database, allowing objects with the same name to exist in different schemas. For instance, you can haveÂ
Sales.Customers andÂSupport.Customersin the same database. Why you would want to do that remains to be seen! Just because you can, doesn’t mean that you should! -
Simplified Maintenance:Â Schemas can make database maintenance tasks more straightforward by grouping related objects together, facilitating easier backups, restores, and migrations.
Steps to Create a Schema in SQL Server Management Studio (SSMS)
Creating a schema in SSMS is a straightforward process. Follow these steps to create a new schema:
-
Open SQL Server Management Studio:Â Launch SSMS and connect to your SQL Server instance.
-
Connect to the Database Engine:Â In the “Connect to Server” window, select the appropriate server type, server name, and authentication method, then click “Connect.”
-
Expand the Database:Â In the Object Explorer, expand the database in which you want to create the new schema.
-
Navigate to Security Folder:Â Expand the “Security” folder within the database.
-
Right-click on Schemas: Right-click the “Schemas” folder and select “New Schema…”

-
Define Schema Properties:Â In the “Schema – New” window, enter a name for your schema in the “Schema name” field.
-
Specify Schema Owner:Â Optionally, you can specify an owner for the schema by entering a database user or role in the “Schema owner” field. If left blank, the default owner is the user who creates the schema.
-
Create the Schema: Click “OK” to create the new schema.

-
Verify Schema Creation:Â In the Object Explorer, expand the “Schemas” folder to see the newly created schema listed among existing schemas.
By following these steps, you can easily create and manage schemas in SQL Server, enhancing your database objects’ organisation, security, and manageability.
This can also be done through T-SQL, the code for the above is as follows
USE [HelpDesk]
GO
CREATE SCHEMA [MySchema]
GO
Conclusion
So that was a short post on schemas. I wanted to cover those off before we get into creating tables. I expect most of you reading will have tables that ALL belong in the dbo schema. That’s OK but you now know there is another way
Don’t miss out! Subscribe to our blog for more insightful posts and updates. Let’s embark on this SQL Server journey together!
Useful Links
You might like some of the following
0 Comments