Datasheet

This chapter provides an overview to the rest of the book. Everything discussed in this chapter will be
covered again in later chapters, but this chapter is intended to provide you with a roadmap or plan to
bear in mind as we progress through the book. As such, in this chapter, we will take a high-level look into:
Database objects
Data types
Other database concepts that ensure data integrity
An Overview of Database Objects
An RDBMS such as SQL Server contains many objects. Object purists out there may quibble with whether
Microsoft’s choice of what to call an object (and what not to) actually meets the normal definition of an
object, but, for SQL Server’s purposes, the list of some of the more important database objects can be said
to contain such things as:
The database itself Indexes
The transaction log CLR assemblies
Tables Reports
Filegroups Full-text catalogs
Diagrams User-defined data types
Views Roles
Stored procedures Users
User-defined functions
The Database Object
The database is effectively the highest-level object that you can refer to within a given SQL Server.
(Technically speaking, the server itself can be considered to be an object, but not from any real “pro-
gramming” perspective, so we’re not going there.) Most, but not all, other objects in a SQL Server are
children of the database object.
If you are familiar with old versions of SQL Server you may now be saying, “What? What happened to
logins? What happened to Remote Servers and SQL Agent tasks?” SQL Server has several other objects
(as listed previously) that exist in support of the database. With the exception of linked servers, and per-
haps Integration Services packages, these are primarily the domain of the database administrator and as
such, you generally don’t give them significant thought during the design and programming processes.
(They are programmable via something called the SQL Management Objects (SMO), but that is far too
special a case to concern you with here. We will look at SMO more fully in Chapter 25.)
A database is typically a group that includes at least a set of table objects and, more often than not, other
objects, such as stored procedures and views that pertain to the particular grouping of data stored in the
database’s tables.
2
Chapter 1
04_584340 ch01.qxp 10/18/06 2:11 PM Page 2