This is a lengthy, but easy read. It is written for someone with little or no development training or experience. It leads the reader by the hand through the design process, including almost every possible detail (for example, questions to ask during interviews with users and management). If you are someone with development experience, the level of detail can, at times, be almost insulting. At one point in the book, the author not only tells you what size paper to use, but also how to place it on the desk, and how to write on the paper.

The purpose of a good design is to guarantee data integrity, and to ensure that the information retrieved from the database is accurate, reliable, and meaningful. Hernandez describes a design technique without any discussion of normalization. A central theme in all other discussions of relational database design, normalization is relegated to a white paper on the CD included with the book. The author does this because many professional developers have difficulty understanding normalization, so someone just beginning to do designs can quickly become overwhelmed by the concept. Because of this void, and because of his dependence on traditional methods, the author forces himself, and the reader, to follow a very lengthy and tedious process to get to a good database design.

Four parts make up the book: “Relational Database Design,” “The Design Process,” “Other Database-Design Issues,” and “Appendixes.” Part 1 provides a history of the relational model and of the models preceding it, a discussion of design objectives, and an explanation of terminology.

In Part 2, Hernandez spends more than 400 pages describing his technique, including the use of dozens of meetings with representatives of users and management. This in itself will ensure job security for a long time. Even though the process is long and tedious, it does represent some excellent procedures for creating documentation of the database design. Hernandez is not breaking new ground; he uses an enhanced version of the waterfall development methodology. He also emphasizes procedures many experienced developers use instinctively. By doing this, he is allowing an inexperienced database designer to create a good design, comparable to one created by someone with years of experience. But to benefit from this process, you must follow his design methodology faithfully, and to the letter.

Part 3 addresses database design issues that the author thinks are separate from his preceding discussion; in reality, they are just a continuation. These issues include bad design and bending or breaking rules. The whole book has worked to help readers avoid a bad design, so this discussion is really just a restatement of the major tasks. When it comes to a discussion of whether to bend or break the rules, the author says only to not do it unless it is absolutely necessary. This is because he does not address normalization, so a discussion of de-normalization is impossible; instead, the process adds extra work to ensure a normalized design.

A CD comes with the book, which contains the appendices and the white paper on normalization. Appendix D contains printable copies of the forms used by Hernandez in his design process. There are forms for field specifications, business rule specifications, and view specifications. These forms are very detailed, and contain a wealth of information. Filling in these forms forces the designer to answer critical, but easily forgotten questions (for example, which tables share a particular field). The book also has a glossary of database terminology, and a very easy to use and functional index.