To me, this book's value is a bit like children being warned not to accept lollies from strangers; it's a pity we even have to give such warnings, but it's absolutely essential we do. I wish to congratulate Simsion for bravely tackling a subject of much heated controversy, and in a manner that obviously reflects both a solid practitioner's hard-won lessons, but that is supported by rigorous academic research.
So what's this important message? Simply that data modelling is a creative exercise, where multiple "solutions" may be generated, each with relative merits. The importance lies in practitioners consciously and deliberately generating alternatives. Without this open-minded view, I have personally witnessed heated debates where one modeller defends his/her model because they know it can be made to work, and therefore assumes anything different must be "wrong". But even more significantly, modellers may stop looking as soon as one "workable" model is tabled, and hence miss out on alternatives that may prove beneficial in a given business context.
And why is it even controversial? Apparently, some academics teach data modelling that way. Maybe because it's easier for them to have one "correct" answer to a problem so marking assignments is easier? Or maybe that was what they were taught, and any students who pass through their ranks and end up teaching without encountering real-world modelling may perpetuate?
One warning, though. This book is not the first text to be read by those interested in data modelling. I would recommend Simsion & Witt's "Data Modelling Essentials for such people, followed by one of many excellent books on "patterns". David Hay got the patterns topic going in the data modelling community, and Len Silverston's two volume series has taken it much further. And the object-oriented community also has contributions to make on patterns.
A minor criticism - Simsion largely dismisses the use of the Unified Modeling Language's class modelling notation, in part arguing that "Class diagrams are intended to represent data structures which might be directly implemented using an object-oriented database" and goes on to correctly note the struggle of such databases to gain significant database market share that their vendors initially might have predicted. I would simply comment that there is a difference between using a subset of the class modelling syntax to represent what is truly a data model, as compared to using class modelling notation to represent classes which, in some cases, may never have "persistence" i.e. may never have their data values stored in a database of any kind. And even if class diagram notation is used (some might say misused?) just to represent a data model, I have seen this approach used quite effectively. So on this point, it looks like Simsion and I have slightly different views. But at the very heart of his book, he encourages open debate on alternative views, with the understanding that all views may have something to contribute.
So let's thank Simsion for offering his views, and encouraging others to offer theirs. Well done, it's a great reference book (probably not easy reading for those not exposed to research styles - but don't let that put you off), and one that hopefully bridges the gap between academics and practitioners, and gives the practitioners "permission" to be creative as most know is the way to generate alternative solutions for consideration.