End users may have a need to do some form of reporting of data from source systems. Opening up the database tables to end users normally isn’t the best practice, but different situations often require different implementations right? In this blog series, I am going to show you one method of limiting access to the tables containing your data, while also providing the needed data for your’ end users.

For part 1 of this two part series, I am going to show you how you can create a schema that will be used to add your objects to (in my case Views). Next I’ll show you how you can add a view to the schema. Before getting started into this series, let’s make sure we’re all set up to follow along. I will be using the AdventureWorks database. If you already have it, great! If not, you can find it on CodePlex.com. Next, you will need to be able to alter objects in the AdventureWorks database. If it is your local test box (which most of the time it will be), then you should be all set! J

Let’s fire up SQL Server Management Studio (SSMS) and open a new query. In this first step, we are going to create a schema that will be used to assign our views to. This will make it easier to manager what objects your “reporting” users will be accessing.

Script 1: Create Schema

USE AdventureWorks

GO

CREATE SCHEMA Reporting

GO

Next, let’s create a sample view that can be used to limit columns that the report user can access. Be sure to add it to the Reporting schema that we just created. If you are new to views, basically a view is a database object which allows you to use it as you would a table. They are very useful when you need to join multiple tables together, filter results or limit the ability to see columns in base tables. Script 2 below retrieves a limited amount of columns from the Employee and Contact tables.

Script 2: Create a View

CREATE VIEW Reporting.vw_Employee

AS

SELECT

      [E1].[LoginID]

      , [C].[FirstName] + ' ' + [C].[LastName] AS EmployeeName

      , [E1].[Title]

      , [E1].[HireDate]

  FROM

      [AdventureWorks].[HumanResources].[Employee] E1

      JOIN [AdventureWorks].[Person].[Contact] C ON E1.ContactID = C.ContactID

GO

Now let’s make sure that we are getting results as shown in figure 1 below.

Figure 1: Select From Your New View

I think we have a good base on creating schemas and adding views to them. In my next blog, I will show you how to create a new SQL Server login and grant access only to the views under the Reporting schema.

Until next time, “keep your ear to the grindstone” – Good Will Hunting

Brian K. McDonald, MCDBA, MCSD
Business Intelligence Consultant – Pragmatic Works Consulting

Email: bmcdonald@pragmaticworks.com | Blog: BI Developer Network

Convert with DTS xChange  | Develop with BI xPress  | Process with TaskFactory | Document with BI Documenter