DATA MODELING OVERVIEW - A Developer's Guide to Data Modeling for SQL Server - page 20

Additionally, you will probably end up with tables that contain data not
represented in your logical model. We call these supporting tables. They
are used to support the use of the database but do not necessarily store
data that the business cares about. Supporting tables might be lookup ta-
bles or tables to support application code, or they might support business
rules. For example, suppose that the business requires that all users belong
to a group, and their group membership determines the access they have
in an application. This security model can be stored in tables and refer-
enced by the application.
Except for these differences, building the physical model is similar to
building the logical model. You still need to determine the needed tables,
columns, primary keys, and foreign keys, and diagram them in a model.
SQL Server has other objects in addition to tables. Objects such as
views, stored procedures, user-defined functions, user-defined data types,
constraints, and triggers can also be used in your physical model. We look
at these objects in detail in Chapter 3, and we describe how to build a
physical model in Chapter 9, Creating the Physical Model with SQL
Server.
Indexing
The next big part of implementing your database on SQL Server is index-
ing: Indexes are structures that are placed on tables in a physical database
to help enhance performance by giving the database engine reference
points to find the data on disk. Deciding what types of indexes to use and
where to use them is a bit of a black art, but it is a critical part of your data-
base. Index requirements are largely driven by business rules and usage in-
formation. What data does the business need to retrieve quickly? Will a
given table typically be written to or read from? Answering these questions
goes a long way toward determining your indexes. We look at indexes and
explore considerations for implementing them in Chapter 10, Indexing
Considerations.
Creating an Abstraction Layer
Another important, and often overlooked, part of database design is the ab-
straction layer. An abstraction layer provides a level of access to the data-
base without giving users direct access to the tables. To create an
abstraction layer, you create views, stored procedures, and functions to ac-
cess the data in the underlying tables.