Datasheet

Chapter 1 ✦ The Information Architecture Principle

restore the database and the transaction log to another server. A solution is to maintain a

warm backup server on ready standby so that if the primary server fails, then the warm

standby comes online with minimal availability impact.

Recovery

The availability method of last resort is to restore the database and recover the data from

backup files. Recovery requires more than just a backup file. The write-ahead transaction log

provides a way to recover all transactions committed since the last database backup.

Extensibility

The information architecture principle states that the information must be readily available

today and in the future, which requires that the data store is extensible, able to be easily

adapted to meet new requirements. As an industry, data integrity, performance, and availabil-

ity are all mature and well understood, so the next major hurdle for the industry to conquer

is extensibility.

Two design concepts lead to an extensible system: decoupling the database using an abstrac-

tion layer and generalizing entities when possible. Extensibility is also closely related to sim-

plicity. Complexity breeds complexity, and inhibits adaptation.

Abstraction Layer

Many production databases were well designed when they were created, and served their ini-

tial purpose remarkably well, for a while. But as changes are required, the development effort

becomes increasingly difficult and developers begin to complain about the database. Years

later, the development team may still be stuck with a database that no longer serves the pur-

pose but is too difficult to change. The system met the original requirements, but is now

extremely expensive to maintain.

The source of the problem is not the database design, but the lack of encapsulation and cou-

pling between the application and the database. An abstraction layer is the primary method of

decoupling a data store from the application. Without an abstraction layer logically separat-

ing the database from the application, any database is destined to become brittle— the

slightest change breaks an overwhelming amount of code.

A data store abstraction layer is a collection of software interfaces that serve as a gate through

which all access to the database must pass. An abstraction layer is essentially a contract

between the application code and the database that defines each database call and the

parameters. An abstraction layer can be constructed using T-SQL stored procedures, or a

software tier. With an abstraction layer in place and enforced, any direct access to the tables

via SQL DML commands is blocked.

Designing and coding a T-SQL–based abstraction layer is explained in Chapter 25, “Creating

Extensibility with a Data Abstraction Layer.”

An abstraction layer supports extensibility by shielding the application code from schema

changes, and vice versa. The implementation of either side of the contract (data store or

application code) may be changed without affecting the abstraction layer contract or the

other side of the contract.

Cross-

Reference

05_542567 ch01.qxp 9/27/06 9:58 PM Page 19