Politics, project plans, and
budgets—these are some of the major tension areas within many IT
departments. DBAs and developers, in particular, seem to clash often,
because they generally have different priorities. Consider the DBA who
is concerned with maintaining a specific service level agreement (SLA)
and the developer who needs to update an application to support
integration of a new widget. A DBA hears not the need for the update
but that the developer wants to take the application off line, which
would violate the SLA.
Software can’t solve the politics of IT, but it
can mitigate some of the conflicts by providing features and
functionality that help developers focus on developing code and DBAs
focus on maintaining databases and ensuring compliance with the SLAs
they are given. This scenario applies often to data-tier applications.
Defining a Data-Tier Application
A data-tier application contains all of the database and instance objects used by an application. This entity is in reality is a ZIP file known as a dacpac file because of its .dacpac file extension. Theoretically, the developer creates this dacpac
file and gives it to the DBA. The DBA then deploys this application to
one or more instances of SQL Server, on premise or in the cloud via SQL
Azure. The DBA’s job is not so much about micromanaging that specific
application but rather managing all the applications as they relate to
core performance factors like CPU, memory, and disk utilization. This
division of labor is similar to what has happened with system
administrators and the operating system. Given the recent industry push
for virtualization of operating systems, system administrators do not
spend their time managing a specific instance of an operating system;
rather, they look more at the big picture (in their case, at the
virtual host machine) and ensure its health and performance.
You can create a dacpac file out
of an existing database via SSMS. To illustrate the data-tier
application, let’s create a new database for a used car company. To
start, open SSMS, and connect to your test database server. Next, open
a New Query window, and type the following code:
USE MASTER
GO
CREATE LOGIN BobLogin WITH PASSWORD='pass@word1'
GO
CREATE DATABASE UsedCars
GO
USE UsedCars
GO
CREATE USER Bob FOR LOGIN BobLogin
GO
CREATE SCHEMA Sales
AUTHORIZATION Bob
GO
CREATE SCHEMA Product
AUTHORIZATION Bob
GO
CREATE TABLE Product.Inventory
(car_id INT NOT NULL PRIMARY KEY,
car_make VARCHAR(50) NOT NULL,
car_model VARCHAR(50) NOT NULL,
car_year SMALLINT NOT NULL)
GO
CREATE TABLE Sales.Orders
(order_id INT NOT NULL PRIMARY KEY,
order_date DATETIME NOT NULL,
order_carsold INT REFERENCES Product.Inventory(car_id),
order_saleprice SMALLMONEY NOT NULL)
GO
INSERT INTO Product.Inventory VALUES (1,'Saab',
'9-3',1999),(2,'Ford','Mustang',2003),(3,'Nissan','Pathfinder',2005)
GO
At this point, we have a very crude design with two simple tables. The Product.Inventory table contains a list of all cars available for sale. The Sales.Orders
table lists when the car was sold.
We can create a data-tier application out of an
existing database by simply right-clicking the UsedCars database in
SSMS object explorer and selecting Tasks and then “Extract Data-tier
application”. This will launch a wizard that will help us create the dacpac file. The first page where we can enter input is the Set Properties page shown in Figure 1.
Figure 1. The Set Properties page in Extract Data-tier Application wizard
On this page, we can give the application a
formal name and provide a description and a version number. The default
location of our dacpac file will be in a subdirectory within the Documents path. In this example the default path is C:\Users\Administrator\Documents\SQL Server Management Studio\DAC Packages.
The next page in the wizard performs a check to
see if the objects within the database can be exported into a data-tier
application. After these checks are performed, the wizard gives you a
summary of the findings, as shown in Figure 2.
Not all objects within a database can be used
in a data-tier application; this is one of the limitations of using
data-tier applications.
Figure 2. The Validation and Summary page of the Extract Data-tier Application wizard
After you’ve completed the wizard’s steps, the dacpac file will be created. If you navigate to the folder where the dacpac file was created, you can see a single file called UsedCars.dacpac.
Note If you are curious about the contents of the dacpac file, simply rename it to have a .zip extension and unzip its contents. In our UsedCar application example, the dacpac contained four XML files: [Content_Types], DacMetadata, LogicalObjectStream, and PhysicalObjectStream.
If you load one of these XML files, you’ll see that its contents do not
include the actual data of the database, just the database shell.
This data-tier
application packages now contains all the objects needed for the
UsedCars application. If you wanted to deploy the UsedCar application,
simply connect to another SQL Server instance and deploy it.
