Chapter 1 -- Basic Concepts

Chapter 1

So, what is this mythical creature called a relational database? Briefly, it's a tool for storing and manipulating information efficiently and effectively—"efficiently and effectively" in the sense that data is protected from accidental loss or corruption, that it doesn't use more resources (human or computer) than necessary, and that it can be retrieved in sensible ways within acceptable performance constraints. The database itself is the physical implementation of a relational model, which is a way of describing some aspect of the real world according to a set of rules first proposed by Dr. E. F. Codd in the late 1960s.

In theory, a relational database could be coded from scratch, but in reality you'll normally use the services of a database management system (DBMS). A DBMS is sometimes called a relational database management system (RDBMS), but technically a DBMS must meet some 300 rules to qualify as relational, and to the best of my knowledge no commercially available system fully qualifies. The two database management systems we'll be examining in this book are Microsoft Access and Microsoft SQL Server.

I've said that a relational database is the physical implementation of a relational model (the data model), and it's important to keep these two concepts distinct. While it's almost impossible to completely ignore the constraints of the implementation environment during the design phase, best practice dictates that the original model be as "pure" as possible. Although you might already know that for performance reasons you're going to have to make certain trade-offs during implementation, you can, and should, ignore these decisions during data modeling. An example of this is storing calculated fields (such as OrderTotal) in a base table, which is a major no-no in relational design but a common technique in practice. Whatever you choose to do with your implementation, your model should not include the calculated field.