Customer Reviews

Database Modeling and Design, Third Edition (The Morgan Kaufmann Series in Data Management Systems)

5 star:		(3)
4 star:		(2)
3 star:		(1)
2 star:		(3)
1 star:		(0)

 

 

I have no formal schooling in programming, but find myself having developed one major database application and about to embark on another larger project. I bought the book because I wasn't sure if my intuitions about database design were the right intuitions.

Given what I was looking for, the book was excellent. It described (perhaps in dry language) the theoretical underpinnings of a well designed (or normalized) database.

Also, the book gave me the proper smybolic and linguistic tools to tackle the task of DB design in a more organized and effecient process.

In short, it turns out there are very strict rules about what makes a database a well designed database. Given that previously I was designing on intuition alone, I found this book an excellent developmental tool. There were a few things I was doing wrong that I won't do again!

By the way, there are 2 chapters in the book that most people won't use. Or rather, if you need these chapters you probably don't need the other chapters. These are the chapters on geographically distributed database applications and the chapter on how the physical implementation of the database in memory can relate to query optimization.

This is one of the best books I have found for the intermediate-advanced DB designers out there. Most of the other books dwell too much on theory - one of my main gauges for checking out DB Modeling books has been a scan for descriptions on what First and more advanced Normal Forms mean and this book does a great job. It goes step-by-step with plenty of worthwhile examples on why you should attempt to normalize to higher degrees and even on why, as a final step, you may actually want to denormalize (yes, undo some of the work that you've done). This is not a beginner's book - go get SQL for Dummies or the like if you're just getting started. If, on the other hand, you've been creating tables, databases, and indexes for a while and can't quite figure out how to get around a pesky design problem, then this is the perfect book for you.

Ok, yes the book is rather dry. No cute anecdotes here. But, if you bring yourself to really focus on it you'll find DM&D to be a well written book. At a little over 300 pages it did a great job of conveying the major DM concepts concisely yet with enough examples so that the reader can achieve a good level understanding. Also, not having to wade through another 1500 page goliath yet getting the same return, in terms of knowledge acquired, saves me time, my most valuable resource right now. Undisciplined novices may not find it a good 'motivator' book because it does serve up a great deal of information per page mixing both basic information and advanced concepts, this generally leads to rereading a page several times to let a theory and it's implications sink in. All in all I really thought it was a very worthwhile read. It filled a good number of 'holes' in my knowledge of data modeling. I've been doing Oracle database administration for 5 years and hardcore modeling in the last 2. I was pretty good at my job, now I'm even better! Hope this helps!

PREAMBLE: I have experience with creating small DBs in Access and basic SQL and have been a business user of DBs for many years. I am knew to the DB modeling and design world and was looking for an introductory text on conceptual & logical DB modeling. I consider myself a novice.

The GOOD: Chapters 1-5 are done well. The book does a good job of introducing the reader to the Entity-Relationship(ER) model approach using the Chen notation and its extensions. It also does a good job explaining how ER modeling can be applied to a database life cycle, in particular, requirements analysis, conceptual and logical modeling. Also, the transformation of the ER model elements to SQL constructs and the process of DB normalization are explained well. The "real-life" case study helps with the explanations. The book provides an extensive list of literary references.

The BAD: From Chapter 6 and on. It started reading like an academic literature review of all advanced database related topics like Data warehousing (DW), Object-Relation DB(ORDB), and Object-Oriented DB (OODB), OLAP. The topics were covered in a cursory manner and then the reader is directed to the referred reading list for more information. Also, the book becomes much more academic on how the DBMS deals with the physical elements like access methods, indexes, data allocation, execution times, etc. These topics are way to technical for the novice DB user. The book does not really provide any real in-depth informaton on DB modeling and design for the other DB structures/tools discussed (DW,ORDB,OODB,OLAP).

CONCLUSION: The primary reason for the "2 stars" is the misleading commentary that this book would be useful to the novice designer. This book is not for a DB novice, but for intermediate-advanced DBA/Architect/Modeler. Overall, I found the book tries to cover too many topics and in the process diluting all the topics. Leaving the reader with the feeling of not really learning that much. If you are an intermediate-advanced DB user then I can see the book being useful in providing a roadmap to the DB literature while providing a basic introduction. Books of this nature should not try to tap both sides of the experience spectrum; pick one and then stick to that level.

If you're still trying to understand just how relational databases work, don't start with this book. In fact, read several more beginner-level books before trying to deal with this one. I'm half way through and can't say I comprehend any of what I've read. I did read wonderful reviews before I purchased "Database Modeling and Design," so there are many advanced readers who will surely benefit from the dry and technical style of writing and presentation in Teory's book. This is a perfect case of using so many source references that the author forgot to write for the reader, instead of for fellow academics. The marketplace now has a new type of database designer and analyst - those with liberal arts degrees, not engineering!

This book takes the technology of 'readability' to new lows. The author clearly takes much pride in his extensive knowledge of the English language. I'm not saying you won't get useful information from this book, it's just such a painful process. We all had classes we enjoyed and those that put us to sleep. This is the class you had to bring coffee to. It's also an invaluable resource if you want to learn countless stringent guidelines for drawing an ER diagram.

This book gives you guidelines on how to design a database. These guidelines do not assume that you know anything about databases, but do assume that you have lived through at least one major development project before. This is not a quick-start "how to" book, nor will it explain how to use relational database software; the guidelines are more along the lines of "Classify multivalued attributes as entities," and "Attach attributes to the entities they most directly describe."

The exercises were useful and informative, and the author presents the material in a concise and clear way, free of typographical silliness or excessive personal familiarity, neither of which would contribute in any way to the material. The style is, roughly, 10% textbook, 90% cookbook.

This is a great book on building databases the correct way. I highly recommend this book and if you cannot understand it you shouldn't be building a database anyway. It covers everything you need to know from normalization to ERD's (Entity Relationship Diagrams). I use it all the time to brush up on techniques that become rusty after not using them for a while!

I have experience on commercial website databases with 10000+ users per month, and picked up Teory's book to look for a primer or for some pointers. I am fairly frustrated in trying to get through this book to find straightforward explainations.

Alot of database design is common sense. When looking through most DB books, this common sense understanding of database design is blocked by jargon loaded walls of words.

Excerpted example of befuddled writing:
"Analyze redundant relationships carefully. Two or more relationships that are used to represent the same concept are considered to be redundant. Redundant relationships are more likely to result in unnormalized tables when transforming the ER model into relational schemas. Note that two or more relationships are allowed between the same two entities as long as the two relationships have different meanings. In this case they are not considered redundant." (page. 50, 3rd ed.)

That was an example of the paragraphs that wastes my time, and irks me to want to tear my hair out. Shall we posit that: 'the expository text therein displayed above for the reader is an example of the endemic pomposity of academic writing that conveys ideas in a form that is far from concise; nay, in fact in a form that is too wordy.' Or am I being redundant?

I have no wish to be too harsh, it does have some valuable DB knowledge at an academic level. It is to be lauded for being a computer book on a substantial topic weighing under 400 pages. But please: to DB & academic writers out there -- drop the pretension, and cut down on your verbiage, and get to the point in a plainly said style.

[The ratio of : (words of Jargon)/(practical information conveyed) = the average overcharge submitted by the job title in question, and the artificiality of the barrier to becoming a competing member of that profession.]