Tài liệu MASTERING SQL SERVER 2000- P4 docx

CHAPTER 4 • DATABASE DESIGN AND NORMALIZATION
120
Third Normal Form
The rules for Third Normal Form are that the database must be in Second Normal
Form and that all nonkey fields must directly depend on the primary key. The most
obvious violations of Third Normal Form are calculated fields. If you design an
Invoice table that includes Quantity, Price, and TotalPrice fields (with TotalPrice being
simply Quantity multiplied by Price), you’ve violated Third Normal Form. You can
derive the total price any time you need it by knowing the Quantity and Price values
for the record. Storing it requires you to make multiple changes to keep the record
self-consistent any time you must change one of these fields.
Third Normal Form also helps you see that some tables need to be split into multiple
pieces. For example, in the Second Normal Form of the animal feed example, if a sup-
plier moved to a different city, you’d need to make changes to more than one row of
the Feed table. This is an inefficient and potentially error-prone process. You’re better
off moving the list of suppliers and cities to its own table. Tables 4.8, 4.9, and 4.10 show
the animal feed database in Third Normal Form.
Another way to think about Third Normal Form is that it’s concerned with making
each table contain information about only one thing. In the Second Normal Form
version of these tables, the Feed table contained both facts about feeds and facts
about suppliers. Now the supplier facts are in their own table. There is still a Supplier-
Name field in the Feed table, because you still need to be able to trace the relation-
ships between the tables and preserve referential integrity. Also, you can use the Breed
field in the Animal table and the Breed field in the Feed table to trace the relation-
ships between animals and feeds. For example, llamas eat pasture and llama feed.
TABLE 4.8: ANIMAL TABLE IN THIRD NORMAL FORM
Name* Breed
Danny Horse
Tango Llama
Scotty Llama
Genghis Goat

2627ch04.qxd 8/22/00 10:02 AM Page 120
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
121
TABLE 4.9: FEED TABLE IN THIRD NORMAL FORM
Breed* Feed* SupplierName
Horse Pasture Jones
Horse Sweet Feed Grange
Llama Pasture Jones
Llama Purina Llama Feed Grange
Goat Hi-Pro CostCo
TABLE 4.10: SUPPLIERCITY TABLE IN THIRD NORMAL FORM
Supplier* City
Jones Endicott
Grange Colfax
CostCo Spokane
Boyce-Codd Normal Form
There’s still one problem with the feed tables in Third Normal Form. Although the
SupplierName field in the Feed table does depend on the primary key of the table
(that is, knowing the Breed and Feed, you can deduce the SupplierName), the field
depends on only a part of that key. So if you decide to buy a type of feed from a
different supplier, you might need to fix multiple rows of the table.
Boyce-Codd Normal Form, sometimes called BCNF, adds the restriction that
every column not in the primary key must depend on the entire primary key. This
is not the case in Table 4.9 (in the previous section), because the Supplier depends
only on the Feed column. Once again, the problem can be remedied by splitting the
tables further. Tables 4.11 through 4.14 show the example feed database in BCNF.
BOYCE-CODD NORMAL FORM
Introducing
SQL Server
PART

I
2627ch04.qxd 8/22/00 10:02 AM Page 121
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 4 • DATABASE DESIGN AND NORMALIZATION
122
TABLE 4.11: ANIMAL TABLE IN BCNF
Name* Breed
Danny Horse
Tango Llama
Scotty Llama
Genghis Goat
TABLE 4.12: FEED TABLE IN BCNF
Breed* Feed*
Horse Pasture
Horse Sweet Feed
Llama Pasture
Llama Purina Llama Feed
Goat Hi-Pro
TABLE 4.13: FEEDSUPPLIER TABLE IN BCNF
Feed* Supplier
Pasture Jones
Sweet Feed Grange
Purina Llama Feed Grange
Hi-Pro CostCo
TABLE 4.14: SUPPLIERCITY TABLE IN BCNF
Supplier* City
Jones Endicott
Grange Colfax
CostCo Spokane
2627ch04.qxd 8/22/00 10:02 AM Page 122

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
123
If you examine these tables and think about the sorts of information you might
like to change in the database, you can see that any potential change will affect only
one row of a table at a time. This is the end result of normalization: a set of tables that
can be updated easily without the need to change more than one piece of data at a
time to make the updates.
Advanced Normalization
It’s worth mentioning that BCNF is not the end of the road for normalization. Data-
base researchers have identified additional normal forms, including Fourth Normal
Form and Fifth Normal Form. For most everyday databases, though, putting your
tables into BCNF should be sufficient. In fact, if your database is relatively straightfor-
ward, it may already be in Fifth Normal Form when you design it in BCNF. If the data-
base is complex enough to be subject to the problems that lead to Fourth and Fifth
Normal Forms, you might want to consult someone who does a lot of normalization
for guidance.
Fourth Normal Form
Fourth Normal Form addresses the issues that arise when there are dependencies of
sets of entities. For example, suppose you’re designing tables for a database used by a
college math department to track course assignments. There might be a set of books
used in each course and a set of teachers who teach each course. One approach would
be to create a single table as shown in Table 4.15.
TABLE 4.15: EXAMPLE TABLE NOT IN FOURTH NORMAL FORM
Teacher* Course* Text*
George Algebra Fundamentals of Algebra
George Algebra Advanced Algebra
Phyllis Algebra Fundamentals of Algebra
Phyllis Algebra Advanced Algebra
Ethel Geometry Plato’s Solids
Ethel Geometry Mickey Does Geometry

Adam Geometry Plato’s Solids
Adam Geometry Mickey Does Geometry
ADVANCED NORMALIZATION
Introducing
SQL Server
PART
I
2627ch04.qxd 8/22/00 10:02 AM Page 123
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 4 • DATABASE DESIGN AND NORMALIZATION
124
This table is in Third Normal Form, but it still suffers from a problem when you try
to insert a new teacher for an existing course with multiple texts. For example, if you
added another teacher for the Geometry course, you’d have to add two rows to the
table, one for each text used in the course.
In this case, the table contains what is called a multi-valued dependency. The
course doesn’t determine the teacher uniquely, but it does determine a set of teachers.
The same applies to the relation between course and text—the course doesn’t deter-
mine the text, but it does determine a set of texts.
To obtain Fourth Normal Form, you can break this single table down into two
tables, one for each relation implied in the first table. These two tables are shown in
Tables 4.16 and 4.17.
TABLE 4.16: COURSETEACHER TABLE IN FOURTH NORMAL FORM
Course* Teacher*
Algebra George
Algebra Phyllis
Geometry Ethel
Geometry Adam
TABLE 4.17: COURSETEXT TABLE IN FOURTH NORMAL FORM
Course* Text*

Algebra Fundamentals of Algebra
Algebra Advanced Algebra
Geometry Plato’s Solids
Geometry Mickey Does Geometry
Now you can assign a new teacher to a course, or a new text to a course, with only
a single insertion operation. Further, you retain the flexibility to have one teacher
teach multiple courses, which would not be the case if you used Teacher as the pri-
mary key in the CourseTeacher table.
2627ch04.qxd 8/22/00 10:02 AM Page 124
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
125
Fifth Normal Form
Fifth Normal Form addresses an issue where a table can’t be decomposed into two tables
without losing information, but it can be decomposed into more than two tables.
Examples that demonstrate this tend to be highly artificial and difficult to understand,
so we won’t try to give one here. The important thing is to know that Fifth Normal
Form is mainly an academic notion, not one of practical database design. It’s hard to
find such dependencies in any real database, and the inefficiencies they produce are not
large in practice. In other words, it’s not really worth knowing more than this about
Fifth Normal Form.
Denormalization
Just as normalization is the process of arranging data in a fashion that allows mak-
ing changes without redundancy, denormalization is the process of deliberately
introducing redundancy to your data. Theoretically, of course, one should never
denormalize data. However, in the real world, things are not quite that simple.
Sometimes it may be necessary to denormalize data in the interest of performance.
An overnormalized database can be slow on a network due to the number of joins
that have to be performed to retrieve data from multiple tables. For instance, in the
Farms database, suppose you need to know all the cities where you purchased food
for a particular animal. That would require retrieving information from all of the

tables in the database.
TIP
When you are forced to denormalize data for performance, make sure you docu-
ment your decision, so that another developer doesn’t think you simply made a mistake.
Although it’s not possible to tell you exactly how (or whether) to denormalize
tables in all circumstances, we can offer some guidance. If your normalized data
model produces tables with multipart primary keys, particularly if those keys have
four or more columns in them and are used in joins with other tables, you should
consider denormalizing the data by introducing arbitrary surrogate keys. Identity
columns, combined with UNIQUE constraints, provide a convenient means for
creating these surrogate keys. You can then add arbitrary foreign keys to tables that
join back to the main table and enforce the join on the surrogate keys instead. This
will often provide a substantial performance benefit, because SQL Server can resolve
the relationships faster between tables if those relationships are represented in a
single field.
DENORMALIZATION
Introducing
SQL Server
PART
I
2627ch04.qxd 8/22/00 10:02 AM Page 125
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 4 • DATABASE DESIGN AND NORMALIZATION
126
If producing calculated values such as maximum historic prices involves complex
queries with many joins, you should consider denormalizing the data by adding cal-
culated columns to your tables to hold these values. You can use triggers to ensure
that these calculated columns are updated whenever one of the columns that they
depend on is updated (for more on triggers, see Chapter 14).
If your database contains extremely large tables, you should consider denormaliz-

ing the data by creating multiple redundant tables instead. You may do this either by
column or by row. For example, if an Employees table contains many columns and
some of these (such as hire date) are very infrequently used, it may help performance
to move the less frequently used columns to a separate table. By reducing the volume
of data in the main table, you can make it faster to access this data. If the Employees
table is worldwide and most queries require information about employees from only
one region, you can speed up the queries by creating separate tables for each region.
If data is no longer live and is being used for archiving, or is otherwise read-only,
denormalizing by storing calculated values in fields can make certain queries run
faster. In this case, you might also consider using Microsoft Analysis Server to store
the nonlive data for fast analysis. We’ll talk about Analysis Server in Chapter 27.
TIP
If you split a table into multiple tables by row, you can still query all the data by using
the Transact-SQL UNION operator. You’ll learn about the UNION operator in Chapter 6.
If queries on a single table frequently use only one column from a second table,
consider including a copy of that single field in the first table. For example, you might
choose to include the SupplierCity field in the Feed table, even though the table
already includes the SupplierName, because you always print your shopping list orga-
nized by the city where each feed store is located. In this case, of course, you’ll need to
write code to ensure that the SupplierCity field is updated every time the Supplier-
Name is changed. This code might take the form of a stored procedure that is used to
update supplier information.
WARN I NG
Remember that you should never denormalize your data without a spe-
cific business reason for the denormalization. Careless denormalization can ruin the
integrity of your data and lead to slower performance as well—if you denormalize too far,
you’ll end up including many extra fields in each table, and it takes time to move that extra
data from one place in your application to another.
2627ch04.qxd 8/22/00 10:02 AM Page 126
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

127
Making the Trade-offs
So, given a list of rules for normalization and a set of ideas for denormalization, how
do you make the trade-offs between the two? Although it’s impossible to give a cook-
book recipe for coming up with the perfect database, here’s a strategy that’s worked
well for many people in practice:
1. Inspect the data to be stored in your database. Be sure you talk to end users at
this point to get a sense of what they really need to know. Don’t just ask about
what they think needs to be stored, ask what they need to do with the data.
Often this last step will reveal additional data that needs to be stored.
2. Normalize the database design to BCNF.
3. Armed with the BCNF design of the database, review the list of operations that
users wish to perform with the data. Make sure that there’s enough data to per-
form each of these operations. Also make sure that none of the operations
require multiple simultaneous rows to be updated in the same table (a sign that
you’ve not completely normalized the database).
4. Implement the BCNF version of the database. Build the necessary user interface
to allow users to work with the data.
5. Deploy a pilot version of the application.
6. During the pilot program, collect information using SQL Profiler on all opera-
tions performed.
7. Use the SQL Profiler information to tune the indexes in your database. Inspect
the SQL Profiler information to identify bottlenecks. SQL Profiler was covered in
Chapter 3, and you’ll learn about index tuning in Chapter 25.
8. Interview users to identify any operations during which the database isn’t per-
forming quickly enough.
9. Use the information from steps 7 and 8 to selectively denormalize the database.
10. Repeat steps 5 through 9 until the database delivers adequate performance.
TIP
If you must maintain the design of a large database with many tables, or if you’re

frequently involved in database design projects, you may find a third-party design product
to be helpful. These products allow you to concentrate on the logical design of the data-
base and automatically produce the physical design to match. Tools in this category
include Platinum ERwin ( />and Visio Enterprise ( ).
DENORMALIZATION
Introducing
SQL Server
PART
I
2627ch04.qxd 8/22/00 10:02 AM Page 127
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 4 • DATABASE DESIGN AND NORMALIZATION
128
Tools for Normalization in SQL Server
SQL Server supplies a number of tools that help you maintain your database in a nor-
malized form. These tools help make sure that only sensible data is inserted in tables
and that only sensible changes can be made. Anytime you can enforce normalization
directly at the server, you don’t have to write application code to do so. This is a big
win for most databases.
In this section, we’ll look briefly at these tools:
• Identity columns
• Constraints
• Rules
• Declarative referential integrity
• Triggers
• Database Diagrams
All of these tools are covered in more detail later in the book, but let’s get the big
picture before we dig into the details.
Identity Columns
A simple tool for enforcing entity integrity is the identity column. An identity column

is a column in a table for which SQL Server automatically supplies values. By default,
the first value is 1, and each succeeding value is one more than the previous value,
but both the starting value (the seed) and the increment can be specified by the data-
base designer.
An identity column provides a handy way to include a surrogate key in a table’s
design. Surrogate keys often lead to enhanced database linking by relating tables on
small numeric columns rather than more natural textual data.
NOTE
You’ll learn how to create identity columns in Chapter 11.
Constraints
SQL Server uses constraints to enforce limitations on the data that can be entered into
a particular column in a table. Constraints are rules that govern what data is accept-
able for a particular column in a table. You can use UNIQUE, DEFAULT, and CHECK
constraints to enforce entity, domain, and user-defined integrity. In addition, SQL
2627ch04.qxd 8/22/00 10:02 AM Page 128
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
129
Server uses PRIMARY KEY and FOREIGN KEY constraints to implement referential
integrity. These two types of constraints are discussed in their own section later in
this chapter.
Chapter 8 shows you how to create constraints when you’re building tables in your
own databases.
TIP
If a constraint is violated, the command that caused the violation is terminated and
has no effect. However, if this command is part of a batch transaction, the transaction will
continue. If statements in a transaction may violate constraints, you should check the value
of the @@ERROR global variable and execute a ROLLBACK TRANSACTION statement if the
@@ERROR variable is not equal to zero. Chapter 8 has more information on using transac-
tions in SQL Server.
UNIQUE Constraints

A UNIQUE constraint specifies that all values in a given column must be unique; that
is, the column must have a different value in every row in the table. A table can have
multiple UNIQUE constraints, in which case they must all be satisfied for every row.
UNIQUE constraints bring entity integrity to a table because they guarantee that
every row is different. Any table that has a primary key consisting of a single column
should also have a UNIQUE constraint applied to this column. If you’re using SQL
Server’s declarative referential integrity (DRI), SQL Server will automatically create a
unique index on this column for you.
WARN I NG
If you’ve used Microsoft Access, you might expect a SQL Server identity
column to automatically enforce entity integrity, but this is not the case. You can insert
duplicated values into an identity column. To enforce entity integrity, you should also apply
a UNIQUE constraint to the column.
DEFAULT Constraints
A DEFAULT constraint gives you a way to supply a default value for a column in any
table. That is, the constraint provides the value that will be stored with new rows in
the data when the value for the column is not otherwise specified. DEFAULT con-
straints can help enforce domain integrity by providing reasonable values for new
records. They also help with some user-defined integrity problems: For example, all
new customers might start with an account balance of zero.
TOOLS FOR NORMALIZATION IN SQL SERVER
Introducing
SQL Server
PART
I
2627ch04.qxd 8/22/00 10:02 AM Page 129
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 4 • DATABASE DESIGN AND NORMALIZATION
130
CHECK Constraints

A CHECK constraint allows you to control the data entered into a particular column by
evaluating an expression. The expression must return a Boolean value. If the return
value is False, the constraint has been violated, and the command that caused the vio-
lation will be terminated. CHECK constraints are useful for setting limits on acceptable
data to enforce domain integrity, as well as for enforcing more complex user-defined
integrity rules.
Rules
Rules provide another means of enforcing domain and user-defined integrity rules
within your database. The easiest way to think of a rule is as a reusable constraint. A
rule is a separate SQL Server object that can be bound to one or more columns in one
or more tables.
TIP
A single column can have only one rule bound to it. If you need multiple con-
straints on one column, use CHECK constraints instead of rules.
You’ll learn more about rules in Chapter 11. However, you should note that rules
are largely obsolete now that constraints can perform all of their duties.
Declarative Referential Integrity (DRI)
Declarative referential integrity (usually called just DRI) is a process that allows you to
notify SQL Server of the referential integrity between tables and to have the server
automatically enforce these relationships. Prior to the implementation of DRI, keep-
ing referential integrity enforced required writing trigger code for every table to per-
form appropriate actions under developer control. Now that SQL Server can do this
automatically, performance has improved, and the developer has more time to work
on other parts of the application.
NOTE
A trigger is a bit of code that causes one action to initiate another. You can read
more about triggers in Chapters 14 and 15.
As with other integrity support, DRI is implemented using constraints on tables.
Two types of constraints are used: PRIMARY KEY and FOREIGN KEY. We’ll look at
each of these in turn. PRIMARY and FOREIGN KEY constraints are covered in detail in

Chapter 11.
2627ch04.qxd 8/22/00 10:02 AM Page 130
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
131
Primary Keys
In SQL Server databases, the primary key of a table performs two duties. First, because
it is guaranteed to be unique on every record, it enforces entity integrity. Second, it
serves as an anchor for referential integrity relationships from other tables.
Foreign Keys
Foreign keys, in conjunction with primary keys, provide the other half of SQL Server’s
implementation of referential integrity. A foreign key is a copy of the primary key in
the parent table that is inserted in the child table to create a relationship between the
two. Just like primary keys, foreign keys are implemented with CONSTRAINT clauses.
Unlike with primary keys, a single table can have multiple foreign keys.
TIP
The datatypes and sizes of columns in a foreign key must match exactly the corre-
sponding columns in the primary key.
Cascading Referential Integrity
SQL Server 2000 is the first version to offer cascading referential integrity. This is a fea-
ture that, while still preserving referential integrity between tables, allows a wider
range of operations than would otherwise be possible.
To see the effect of cascading, consider a related pair of tables, Customers and
Orders. In the Customers table, the primary key is CustomerID. In the Orders table,
the primary key is OrderID, and there’s also a CustomerID column that is a foreign
key relating to the Customers table. So, you might have a customer whose Cus-
tomerID is A4511 and then multiple rows in the Orders table, each of which has
A4511 as the CustomerID value and a unique value in the OrderID column.
In a strict referential integrity situation, you’re limited in what you can do with
the record in the Customers table. In particular, you can’t change the value in the
CustomerID column, because that would leave orders that did not refer to a cus-

tomer. You also can’t delete a row from the Customers table if that customer has
orders, because that would also leave orphaned records in the Orders table. Either of
these operations would break the referential integrity between the two tables.
You can implement two types of cascading to get around these problems:
• If a relationship between tables is defined to include cascading updates, when the
value of a primary key in the parent table is changed, the value of the foreign-
key column in all related records in the child table is changed to match.
• If a relationship between tables is defined to include cascading deletes, when a
record is deleted from the parent table, all corresponding records from the child
table are also deleted.
TOOLS FOR NORMALIZATION IN SQL SERVER
Introducing
SQL Server
PART
I
2627ch04.qxd 8/22/00 10:02 AM Page 131
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 4 • DATABASE DESIGN AND NORMALIZATION
132
WARN I NG
Just because you can define relationships to use cascading updates and
cascading deletes doesn’t mean you should always do this. If the primary key of a table
truly is invariant, for example, there’s no point in defining cascading updates. If you need
at all times to be able to retrieve historical information from a database, even if a record
becomes inactive, you won’t want to use cascading deletes.
In SQL Server 2000, you define cascading updates and deletes using the optional
CASCADE keyword when you’re using the ALTER TABLE or CREATE TABLE statement
to create a foreign key. You’ll learn more about these keywords in Chapter 11.
Triggers
Triggers are pieces of Transact-SQL code that can be run when something happens to

a table:
• An update trigger runs whenever one or more rows are updated.
•A delete trigger runs whenever one or more rows are deleted.
• An insert trigger runs whenever one or more rows are added.
Triggers can be as complex as necessary, so they’re an ideal tool for enforcing busi-
ness rules and user-defined integrity. You’ll learn about triggers in Chapter 15.
TIP
In previous versions of SQL Server, triggers were necessary to create relationships
that supported cascades. Now that SQL Server DRI supports cascading, you should use DRI
for all relationships between tables and save triggers for more complex situations.
Database Diagrams
Once you’ve normalized your database, you face the problem of keeping track of your
work. All of the information is available from a listing of tables, columns, and rela-
tionships, but it’s hard to grasp the relationships between tables from such a listing.
SQL Server includes a tool to help you graphically visualize a database design. This
tool is the database diagram. Each database can store as many database diagrams as
you need to keep track of what’s going on.
Figure 4.2 shows a typical database diagram—this one is for the Northwind data-
base that’s shipped as an example with SQL Server.
2627ch04.qxd 8/22/00 10:02 AM Page 132
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
133
FIGURE 4.2
Northwind database
diagram
The database diagram shows each table as a box, with a listing of its columns
within the box. Columns that are a part of the primary key are indicated with the
small key symbol. Lines between the tables show the relationships that are defined
within the database.
NOTE

You’ll learn more about database diagrams in Chapter 11.
Summary
This chapter has introduced you to the basics of database normalization, which is a
key component of design. If you get interested in the topic, a lot more information is
available in books dedicated specifically to that subject. However, for most everyday
SUMMARY
Introducing
SQL Server
PART
I
2627ch04.qxd 8/22/00 10:02 AM Page 133
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 4 • DATABASE DESIGN AND NORMALIZATION
134
purposes, normalizing your data to BCNF is sufficient. You should also consider the
recommendations in this chapter for optimizing and denormalizing your database as
necessary.
You’ve also been introduced to some of the tools that SQL Server supplies for
enforcing normalization within a database. You’ll learn much more about those tools
in the coming chapters. First, though, it’s time to learn about the language used
within SQL Server itself: Transact-SQL.
2627ch04.qxd 8/22/00 10:02 AM Page 134
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
Transact-SQL
PART
II
LEARN TO:
• Understand the
Transact-SQL language
• Use SELECT queries

• Use action queries
• Understand advanced
Transact-SQL
2627ch05.qxt 8/22/00 10:35 AM Page 135
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
This page intentionally left blank
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER
5
Transact-SQL
Overview and
Basics
FEATURING:
What Is Transact-SQL? 138
T-SQL Syntax and Conventions 149
Datatypes 153
Operators 160
Wild Cards 162
Variables 162
Functions 166
Executing T-SQL 175
Summary 186
2627ch05.qxt 8/22/00 10:35 AM Page 137
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 5 • TRANSACT-SQL OVERVIEW AND BASICS
138
N
ow that you’ve had a broad overview of SQL Server and the process of
database design, it’s time to learn how to work within SQL Server data-
bases. SQL, as you probably already know, stands for Structured Query

Language. In this chapter, we’ll begin teaching you how to use this lan-
guage within your own applications. Transact-SQL is a large topic, and detailing it will
take up a large portion of this book. In addition to the introduction in this chapter,
you’ll find significant SQL content in these other chapters:
• Chapters 6 and 7 will introduce you to some common SQL queries.
• Chapter 8 covers some advanced SQL topics.
• Chapter 10 will show you how to use SQL to construct database objects.
What Is Transact-SQL?
Transact-SQL is simply Microsoft’s implementation of the standard Structured Query
Language (SQL). Sometimes called T-SQL, but usually just called SQL (at least by
developers who work with Microsoft products), this language implements a standard-
ized way to ask questions of databases. However, it’s important to understand that
this standard really isn’t all that much of a standard. Although there is in theory a
standardized SQL, in practice the picture is much more complex.
ANSI SQL
The official promulgator of the SQL standard is ANSI, the American National Stan-
dards Institute. ANSI is a body that brings together committees to standardize every-
thing from practices for installing plumbing to computer languages. Among the
products of these efforts is the standard for SQL. The current standard is usually called
SQL-92, because it was finalized in 1992. A more recent version of the standard, some-
times called SQL3 or SQL-99, is just now being finalized. There’s a long road between
standard and products; you’re unlikely to be affected by SQL3 for several years yet.
TIP
If you want to investigate the ANSI standard further, you can visit their Web site at
www.ansi.org. However, you’ll find that all of the ANSI standards are copyrighted, and
none of them are available online. A full copy of the ANSI SQL standard will cost you hun-
dreds of dollars.
2627ch05.qxt 8/22/00 10:35 AM Page 138
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
139

SQL Dialects
Just because there’s a standard on paper doesn’t mean that there’s a standard in prac-
tice. If every vendor of a database product supported exactly the same SQL, life would
be easier for developers, but much harder for marketers. So it is that every real data-
base product diverges from the standard to a greater or lesser extent. Some features
might be implemented differently than the standard specifies. Other features might
be completely nonstandard and vendor-specific extensions to the language. To make
matters more complex, SQL-92 isn’t one standard, but several, since there are various
defined levels of conformance with the standard.
So, is SQL Server ANSI SQL-92 compliant? That proves to be a surprisingly hard
question to answer. Up until 1996, the National Institute of Standards and Technol-
ogy had an official program to test databases for compliance with FIPS-127, a federal
standard that included SQL-92. At that time, SQL Server was compliant with the entry
level of the standard. Since then, the federal testing program has been discontinued,
and SQL Server has been revised.
The bottom line for you, as a developer working with SQL Server, is that most basic
SQL is the same from product to product. What you learn by learning the SQL imple-
mented by SQL Server is close enough to ANSI SQL-92 to give you a head start if you
ever move to a different product.
SQL Configuration Options
Over the years, SQL Server has moved more and more into compliance with SQL-92.
This has posed some problems for database administrators who depended on non-
standard features in previous versions. So SQL Server provides several mechanisms for
adjusting the behavior of its SQL in certain circumstances. These mechanisms—the
SET statement, the sp_dboption stored procedure, and the sp_dbcmptlevel stored pro-
cedure—can be important tools if you’re trying to use an application written for an
older version of SQL Server.
Using SET for ANSI Compatibility
The SET statement is one of the workhorses of the SQL language. You can use SET in
SQL scripts to alter a wide range of server behaviors. In particular, SET can be used to

change some defaults in SQL Server’s processing to adhere to the SQL-92 standard.
Let’s start with one of the possible SET statements having to do with ANSI
compatibility:
SET ANSI_WARNINGS ON
SET ANSI_WARNINGS OFF
WHAT IS TRANSACT-SQL?
Transact-SQL
PART
II
2627ch05.qxt 8/22/00 10:35 AM Page 139
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.