|Database Design for Mere Mortals|
Author: Michael J Hernandez
When a book on database design gets to a third edition, it's almost certainly got something good going for it, and this is a new edition of a very popular book on database design.
The book is split into three main parts – relational database design, the design process, and other database design issues. There are also some meaty appendices. The first part on relational database design gives you the history of database design, what you’re aiming for as a design objective, and what the terminology means. It’s worth noting that Hernandez is firmly on the practical side of the debate, so you’re introduced to records with a note that they’re known as tuples in relational database theory; similarly for fields (attributes), and he uses fields not columns.
Part II of the book covers the design process, and takes up 400 of the 672 pages. Hernandez splits the design process into seven main steps, the first of which rather scarily he calls ‘defining a mission statement and mission objectives’. The thought of mission statements is enough to send most developers running for the hills, but what he means is that you need to get clear from the beginning just what the database should do when it’s finished; this can be a lot trickier than it sounds, and Hernandez is right in that you need to get things clear from the start. That way, when the client says something completely different months down the road, you have evidence! Analyzing the current database comes next, and this could mean the paper-based database you’re replacing.
Creating data structures is the next step, followed by working out the primary and alternate keys for indexing. Field specifications gets its own chapter looking at topics such as field-level integrity, and the physical and logical elements – data types, lengths, uniqueness, required values. Table relationships are covered in the next chapter, and again this topic is tackled from a practical viewpoint rather than as an intellectual exercise. Business rules, views, and data integrity bring this part of the book to a close. Throughout the book, but in this section in particular, Hernandez suggests you make use of paper forms for gathering the information, and there are copies of suitable forms in the book. I have to say that by my estimate, you could end up with hundreds or even thousands of pages of forms to fill in for a typical database, and I’m not sure how practical this would be in the real world.
The next section of the book, Other Database Design Issues, is possibly the most interesting if you’ve got any experience of database design. There’s a chapter on bad design – what not to do; and another on bending or breaking the rules. Both make fun and interesting reading and may teach you more than the rest of the book put together. The book finishes with eight appendices including sample forms, sample designs, and a description of normalization.
The techniques described in the book might at times be unwieldy, but I’d say that if you want to learn how to design a database, you’ll not regret reading this book. There will be parts where you think the point is a bit labored, but you will know how to design a database at the end of it. There’s a reason this is the third edition, and it’s because Hernandez talks sense and writes well.
|Last Updated ( Wednesday, 16 October 2013 )|