Michael J. Hernandez (1997) ‘Database design for mere mortals : a hands-on guide to relational database design’. Reading, MA : Addison-Wesley Developers press.
Many software manuals and help-functions are written in the format ‘If you want to do X, you need to click this button. If you want to do Y, you need to select option this-or-that’. This is why software manuals can be useless to beginners: they don’t explain why you would want to do X or Y. This book tells you all about that. It teaches you how to design a relational database, rather than how some database software package works. That’s why it is worth its weight in gold and probably why 12 years after publication, it is still available on the open shelves of my university’s library.
The chapters
Hernandez takes you by the hand and guides you through an entire method for designing a relational database. He goes from ‘What is a relational database?’ (Ch. 1), to ‘Bending or breaking the rules?’ (Ch. 15). In the second chapter he tries to convince you why you should make a design in the first place before you implement it in software. Then he takes it from the top, asking what is the mission that your database is supporting, which data fields do you need, which tables do they require, what are the key fields, what are the specifications of the fields, how should the tables be related, which business rules should be supported, which views of the data do you need, and how to do a final review of data integrity? The last two chapters deal with what not to do and when and how to break the rules that he has explained in the previous 400 pages.
Every chapter comes with a lot of explanation, introduction of concepts, techniques of how to do the steps of the respective chapter, do’s-and-don’ts, an ample supply of examples, and a case study and summary to round of the chapter. A central element in most of the chapters is sets of rules of how to do things, criteria for what constitutes a good table, field, key, etceteras. Perhaps a particular one dear to me, is ‘What are good names for tables, fields and other elements?’. Hernandez promises that if you follow these rules all will end well with the design of your database, and it seems a solid promise to me.
The end result
After having gone through all the steps in the book, you will end up with a structural design of the database that will fit the business for which it is designed. However, that does not mean, that everything about the business and the database is covered. Hernandez points out that certain business rules can not be implemented through the structure of the database. Instead, they can only be implemented with additional programming in the final application, hence the name ‘application rules’.
The structural design of the database consists of several sets of descriptions, often in the shape of forms, that each describe one particular aspect of the design: every table, field, key, relationship, business rule and view will get its own description. Together with that come the summaries of all the interviews and other documentation you have gathered in the course of the entire process. The whole point of the matter is that you have all that ready BEFORE you start implementing the database. If you think that you will do things in reverse order, think again.
Interviews
In most chapters an important aspect is doing interviews: interviews with the boss, the management and employees. The reason for this is that the database is to serve the client and the users, so their help and input is dearly needed. For those who have never done interviews, Hernandez again takes you by the hand: what kind of questions to ask, how many people to interview, how to prepare the interviewees, and much more. If you have done a lot interviews for research, you will find it all very familiar, which is a good sign if you ask me.
Here are a few things that the author overlooks. One is that the number of interviews you and (many of) the interviewees will go through in the course of the book is quite substantial. It would not hurt to prepare them for that.
Another is that even though the user needs are put first, towards the end of the book, the interviewees are supposed to follow the design of the database and check if everything is in order. I assume that Hernandez has done the work a lot, but I would suspect that not every interviewee would be able to follow.
Lastly, even when interviewees are instructed to stick to answering the questions, they undoubtedly wander off. In my experience as interviewer in social science research projects, it’s not weird that instead of answering question A, interviewees go into follow-up question B, or unknowingly answer D. Or, if you are in bad luck, their answer is not helpful for any of your questions. Anyways, before you start doing interviews, I would suggest to read the entire book first. This way, you will know what to do with a piece of information that is not relevant for the interview at hand, but might already answer a question of a later chapter.
Applying the book for a research database
For the mere mortals who happen to work in research, there is one disappointment: the examples are all geared towards application in business life and administration. So some of the concepts, such as ‘mission statement’ of the database, ‘business rules’, ‘management’ and ’employees’ may be a bit out of your comfort zone. But hopefully, you are smart enough to translate them to your research context. After all, it is not so hard to imagine the mission statement for your database: what is the purpose of your database? And ‘mission objectives’ are the general tasks that the database needs to support.
Perhaps it is even quite helpful to realize that, yes, somewhere there is a boss (the primary investigator), management (the other senior staff) in your research project, and there are the various other roles of post-doctoral fellows, PhD students, MA and BA students, project assistants, technical support staff, and administrative staff, that all may or may not have to do with ‘your’ database. And even if you are convinced that it is just you, then it might be very instructive to include your supervisors and other relevant colleagues, if only to check that you are making sense.
The same goes for asking yourself, well, what is this database actually for? What do I want to do with the data? You should have asked yourself those questions anyways, as part of your research method / plan / design, but just in case you didn’t, this book may offer a welcome reminder.
A second disappointment may be that the book assumes that the database is going to serve more than one person, whereas you may find yourself in a single-person research set-up – not counting your supervisor. You may be an independent research on a non-colaborative project, a postdoc or a PhD student. Moreover, you may not just be the database designer but also the main user. Should you bother with the interviews, you may wonder? Hell yes! And … perhaps no!
‘Yes’, because, as I mentioned above, it could prove very insightful to see what others think about your prospective database. Probably they are very busy, but if you show your sincere interest, they may spare you some time.
‘No’ because you can not actually interview yourself. But, you may be able to find someone who wants to interview you. Perhaps there is a co-worker who is in the same position, so you can interview each other. Or even better, you can design each others’ database. If you cannot find someone to interview you, the most important thing is to articulate the respective answers that the interviews should provide. Just write it all down.
Conclusion
This book is worth your while when you want to design a relational database for your research project.
The bad news: if you’ve read this book, you still need to learn how to use your database management software ( FileMaker Pro, Microsoft Access, MySQL, or what have you). You still need to know which button to press to create a new field, or a table. The good news, after reading this book, you will know a method that results in you knowing which tables and fields you want to create for your research project, and why, and how they relate to each other.
PS. For this review, I read the 1997 print of the first edition. There is a second edition
Rubber Boots Data 
Leave a Reply