Summary

In this chapter, we've looked at translating the conceptual data model into a physical database schema. We began by examining two architectures for structuring the code in your systemthe three-tiered model and the four-layer modelprimarily from the perspective of how the choice of code architecture can impact the database schema.

We've also examined several possible data architectures. A single-tier system locates both the application and the data on the same logical machine. A single-tier application can run as a standalone application, or the data can reside on a network but be accessible only to a single user. Networked applications implemented using the Jet database engine are also logically single-tier, but the data may be accessed by multiple concurrent users.

You can implement two-tiered, or client/server, applications using SQL Server. In this logical architecture, the server machine performs the data manipulation, while the client is responsible for responding to the user. The basic principles of two-tier applications can be elaborated to three or more machines in what is known as an n-tiered application.

We then turned to the translation of the conceptual data model into a database schema. This is usually a straightforward process, as the only new information is the definition of indices and queries to be implemented in the database. Finally, we looked at the impact that security requirements can have on the database schema, and we briefly reviewed the design of a security scheme at the logical level.

In the next chapter, we'll take a quick look at some of the issues involved in communicating your system design to the client and the development team.