 |
|
The year: 1987. Having recently purchased a copy of Oracle for the PC, I upgraded my AT's memory to accommodate the behemoth and then set out to design a relational database that would satisfy all my information needs. I was doomed to failure from the start. I had no practical experience with relational database design and no formal education on the subject. So I dived right in -- and failed miserably. Not for lack of trying but for lack of a good reference book. One that explained logical database design in layman's terms, free of mathematical notation, written by someone with practical experience.
The year: 1997. The book I searched for in vain a decade ago is available now from Addison-Wesley Longman and is titled Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design by Michael J. Hernandez. It meets my criteria for a good relational database design reference. The book explains the logical design of relational databases in layman's terms, free of mathematical notation. It's written by an analyst who has made mistakes, learned his lessons, and now has something to contribute to the volumes already written about relational database design.
Database Design for Mere Mortals focuses on the logical design of relational databases and in doing so spares you any unnecessary platform- and implementation-specific details. In retrospect, this is where I made my biggest mistake. By starting right away to build the database, creating tables and fields, trying to establish relations, etc., in Oracle, I made it difficult to incorporate changes to the logical design as the project progressed. I needed to split the project into discrete phases, beginning with the logical design phase, then, once all the details were worked out on paper, moving on to the implementation phase. Hernandez suggests not even touching a computer until the logical design phase is complete.
The material in the book is presented in three parts: Part I-Relational Database Design, Part II-The Design Process, and Part III-Other Database Design Issues. Hernandez recommends reading the book in chapter sequence. It's good advice because, otherwise, you may lose perspective and start wondering why he's doing things the way he does.
Part I sets the tone for the book, and I recommend starting there. But Part I gives you more than just a framework from which to move on to Part II; Part I is where he wins your confidence by demonstrating that his knowledge of the material is grounded in experience. For instance, although he mentions it in the introduction, he reiterates the distinction between logical design and implementation. He continues by pointing out how naive database designers will jump right in and begin the design process at the implementation phase rather than at the logical design phase. This, he warns, is an approach that once started, makes it extremely difficult to make changes to the database structures as the design progresses. He gives three reasons for adopting an effective logical database design methodology:
"...There are at least three main advantages to learning a good design methodology. First and foremost, it will give you the skills you need to design a sound database structure. Second, a good design methodology will guide you step-by-step through the design process. Third, learning and following a design methodology keeps your missteps and reiterations to a minimum. Of course, you will naturally make some mistakes when you're designing a database, but a good methodology lets you recognize the errors before you've made a major investment of time in them."
After reading this passage you begin to develop a feeling of camaraderie with the author. He understands the issues that confront you, and he knows you're going to make mistakes. However, you can minimize the impact these mistakes have on your project by following an organized database design methodology.
Hernandez concludes Part I by introducing you to the design methodology and terminology used in Part II. In Chapter 3-Terminology, he makes an excellent distinction between data and information:
"It's very important to understand the difference between data and information. A database is designed to provide meaningful information to someone within a business or organization. This information can be provided only if the appropriate data exists in the database and the database is structured in such a way to support that information. When this concept is fully understood, the logic behind the database design process becomes crystal clear."
He could have driven the point home by quoting Stephen Covey, "Begin with the end in mind."
Hernandez does an effective job of relating commonly used terms to formal terminology; for example, "a field (known as an attribute in relational database theory)." This aspect of the book alone makes it user friendly for the novice. However, in the section on Keys, he fails to mention candidate key. Still, I think this is a minor omission since he goes on to give in-depth coverage of candidate keys in Chapter 8.
The meat of the material appears in Part II-The Design Process. Comprised of Chapters 4 through 13, it's here that Hernandez presents, step by step, his seven phase design methodology. Here's a brief sketch of his approach: Draft mission statement and mission objectives, analyze the current database, create data structures (fields and tables), determine and establish table relationships, determine and define business rules, determine and establish views, then review the entire project to assure data integrity. It's clean and systematic. He even walks you step-by-step through the interview process and arms you with effective questioning techniques.
Part II is also littered with gems of wisdom and great ideas. I particularly like how he begins the design phase by writing, with help from management and users in the organization, a mission statement and a set of mission objectives. He then uses these documents to guide him, keeping him focused on the core purpose of the project throughout the design phase.
His various lists are arguably the best part of the book. Beginning in Chapter 7-Establishing Table Structures, he presents the Elements of the Ideal Field list. Then, when necessary, he presents additional lists to help summarize ideal characteristics of various aspects of relational database design. He ultimately provides you with Elements of the Ideal Table, Elements of a Candidate Key and Elements of a Primary Key. He also takes the time and effort to reprint these lists throughout the book, where appropriate, so you don't have to keep thumbing back to refresh your memory.
Although you will find his lists convenient, if you're an experienced analyst you'll find one aspect of the book somewhat amazing. Hernandez clearly demonstrates how to construct a set of relation schemas that effectively enforce the basic precepts of referential integrity without once mentioning functional dependencies and how they're used to reduce tables to the different levels of normal form. Then again, that's what makes his book so easy to read.
I did find one aspect of his methodology strange at first. During management and user interviews he suggests you keep a list of subjects and characteristics. Each list will later be used to design tables and fields. However, instead of starting with the subject list to create the tables, he starts by using the characteristics list. This, he says, helps eliminate any prejudice you may have about what tables should exist. Like I said, I found it strange at first but this technique appears extremely effective in determining required table structures.
You can tell the author did time in the design trenches because he does an excellent job of removing any romantic notion you may have about being a database analyst. His message is clear: It's grunge work -- and taking shortcuts in the design phase will generate more work than it saves.
Part III brings the book to a close with treatments on how not to design a database and when to break the rules. (You'd better have a good reason and make sure you document any rule you break.)
When I read a book I like to give it a thorough going over in search of typos. Alas, I found four. However, they're clearly accidental and should cause you little distraction. One particular typo gave me a chuckle. On page 369, the label for Figure 12-8 reads "Tales from a Contractors database." In this case "Tales..." should read "Tables...". Four typos in a book this size is an accomplishment. I've seen worse...much, much worse.
How can the book be improved? Although an outstanding text in its present form, I think the book's overall effectiveness could be improved by making the various lists available as tear-out cards. Additionally, a comprehensive checklist of his design methodology, also in the form of a tear-out card, would be nice to have.
Who should read this book? For starters, if you're new to relational database design and haven't taken a formal course on the subject, you'll find Database Design for Mere Mortals to be exactly the kind of reference you're looking for: It's clearly written and is packed full of great information. If you've taken a formal course on relational database analysis and design, whether at the undergraduate or graduate level, you will find this book to be a handy reference for the practical application of all that formal theory you learned in class. After all, what good is it to calculate the cover of a set of functional dependencies if you don't know what to do with them when you're done? Experienced database analysts would do well to review the text before the start of each new project. Either way, it will make an excellent addition to your professional library.
Overall, Database Design for Mere Mortals is an outstanding book. Michael Hernandez did an excellent job of making a difficult topic easy to understand.
-- Rick Miller (swodog@pacbell.net)
Forward
Preface and Acknowledgements
Introduction
Part I: Relational Database Design
Part II: The Design Process
Part III: Other Database Design Issues
In Closing
Appendix A: Recommended Reading
Appendix B: Sample Designs
Appendix C: Diagram Symbols
Appendix D: Documentation Forms
References
Index
| Readability |
|
| Originality |
|
| Organization |
|
| Accuracy |
|
| Consistency |
|
| Depth |
|
| Timeliness |
|
| Editing |
|
| Design |
|
| Overall Value |
|
Explanation of ERCB rating scale: No stars = unacceptable, 1 Star = marginal, 2 Stars = average, 3 Stars = above average, 4 Stars = exceptional.